Russian Qt Forum
Ноябрь 21, 2024, 22:55 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Оптимизация работы с памятью  (Прочитано 3307 раз)
Firefox
Новичок

Offline Offline

Сообщений: 7


Просмотр профиля
« : Январь 12, 2022, 09:47 »

Здравствуйте, уважаемые форумчане. Вопрос у меня простой, но хочется услышать мне со стороны.
В программе рассчитываются по математическим формулам массивы значений. Самих массивов данных многовато, но каждый из них не очень большой, например двумерный 30 на 30. Происходит это все в таймере 1 раз в 500 мс. Для расчета конечных массивов используются другие массивы тоже не большие со статическими данными (коэффициентами разными).  Есть у нас один человек на работе, которы любит все эти массивы завести в глобальной области, причем как статические заполненные данными так и массивы с результатами расчетов. Меня это напрягает. Но тут я подумала:данные массивы в памяти выделяются при старте программы и занимают ее до конца программы, что не хорошо. Но при выделении памяти внутри функции например используется ресурс на само выделение и удаление при выходе из функции и так каждые 500мс. Выделение памяти внутри самого класса тоже будет висеть все время работы программы так как у нее это все в основном классе QMainWindow. Вопрос в том, что целесообразнее жертвовать памятью занятой все время работы программы или производительностью. Извините, если вопрос для вас слишком банальный.
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #1 : Январь 12, 2022, 16:10 »

что целесообразнее жертвовать памятью занятой все время работы программы или производительностью. Извините, если вопрос для вас слишком банальный.

очевидно жеж: памятью.

1. память для того и существует, что бы её тратили.

2. операции выделения/удаления памяти чрезвычайно медленные.

3. ты все равно постоянно пользуешься этой памятью.
а значит в любом случае память ты не экономишь.

парень, который сделал глобальные переменные, поступил правильно.




Записан
Firefox
Новичок

Offline Offline

Сообщений: 7


Просмотр профиля
« Ответ #2 : Январь 13, 2022, 11:00 »

Спасибо
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #3 : Январь 13, 2022, 12:24 »

Есть у нас один человек на работе, которы любит все эти массивы завести в глобальной области, причем как статические заполненные данными так и массивы с результатами расчетов.
Эта "детская болезнь" обычно проходит, человек начинает понимать что глобальные массивы не имеют никакой гибкости. Невозможно изменить их размер или избавиться от уже ненужных

Но при выделении памяти внутри функции например используется ресурс на само выделение и удаление при выходе из функции и так каждые 500мс.
Никто не заставляет все время выделять, можно  это сделать один раз. Да и выделять не смертельно (тыкающий знаток выше злорадно шутит), эти затраты намного меньше 1 мс

Вопрос в том, что целесообразнее жертвовать памятью занятой все время работы программы или производительностью.
Здесь этой проблемы нет
Записан
qtkoder777
Частый гость
***
Offline Offline

Сообщений: 245


Просмотр профиля
« Ответ #4 : Январь 13, 2022, 13:28 »

Эта "детская болезнь" проходит, человек начинает понимать что глобальные массивы не имеют никакой гибкости.
левизны в коммунизме?

Современная методология программирования использует концепцию бесконечной памяти. Когда надо выделяем память и забываем про неё. Размен времени на память везде где только можно. Везде кроме непрерывно вертящихся программ это лучший метод.
« Последнее редактирование: Январь 13, 2022, 13:33 от qtkoder777 » Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #5 : Январь 13, 2022, 13:46 »

тыкающий знаток выше злорадно шутит

я не шучу.

new - медленная операция.
delete - ещё более медленная.

мне вот любопытно, ты осознаешь, что два твоих предложение в совокупности дают чушь?




Записан
qtkoder777
Частый гость
***
Offline Offline

Сообщений: 245


Просмотр профиля
« Ответ #6 : Январь 13, 2022, 14:53 »

тыкающий знаток выше злорадно шутит

я не шучу.

new - медленная операция.
delete - ещё более медленная.

мне вот любопытно, ты осознаешь, что два твоих предложение в совокупности дают чушь?
Написать на стене из баллончика слово из трёх букв это операция new. Стереть со стены слово из трёх букв - операция delete.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #7 : Январь 13, 2022, 15:03 »

Современная методология программирования использует концепцию бесконечной памяти. Когда надо выделяем память и забываем про неё. Размен времени на память везде где только можно. Везде кроме непрерывно вертящихся программ это лучший метод.
Пример
Код:
void DoSomething( ... )
{
  std::vector<double> dst;
  ...
  dst.push_back(value);
  ..
}
Ужасный код  Улыбающийся (по крайней мере с точки зрения рекомендации выше). Ведь push_back выделяет память, пусть не каждый раз, но многократно. И по завершении ф-ции вызывается деструктор вектора, а значит безумно медленное delete !

Тем не менее никто не стал бы тут чего-то "оптимизировать", такая мысль даже не зародилась бы. Просто потому что кроме "расходов памяти" и "скорости" есть еще мощнейший аргумент - расходы на написание кода. Даже предвычислить размер вектора часто непросто, это еще "проход". А как-то кешировать вектор такого же размера чтобы вообще избежать (пере)распределений - возможно, но скорее всего выльется не в один десяток строк. И код оптимизации станет источником новых ошибок. Да, исключения есть, но они лишь "подтверждают правило"

Зачем же давать рекомендации которым сами не следуем?  Улыбающийся
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #8 : Январь 14, 2022, 02:12 »

Ужасный код
да. ужассный.
даже для псевдокода.

у всех здоровых людей dst - это получатель данных.
поэтому, если бы код писал моральный человек,
тогда он был бы примерно таким:
Код:
void DoSomething(std::vector<double>& dst)
{
  // ...
  dst.push_back(value);
  // ...
}

тобишь, если в примере-иллюстрации было использованно имя dst,
то и отображаться оно должно как получатель.

а если же у человека изначально не было цели иллюстрировать получателя,
тогда и не нужно вообще использовать имя dst
Код:
void DoSomething()
{
  std::vector<double> sample;
  // ...
  sample.push_back(value);
  // ...
}

а кроме того, в своём аморальном примере, ты допустил двусмысленность:
Код:
void DoSomething( ... )
в языке с++, троеточие - это ключевое слово языка.
причем, по правилам языка, необходимо,
что бы элипсису предшествовал хотя бы один явный параметр.
поэтому, код здорового человека имеет вид:
Код:
void DoSomething(param,  ... )

и вот тут одно из двух:
1. либо ты накосячил, забыв указать явный параметр.

2. либо под элипсисом ты вообще подразумевал не элипсис в терминологии языка,
а просто любой произвольный набор параметров, или что-то в таком духе.
в таком случае это просто вопиюще аморальный поступок.

сознательно коверкать официальную терминологию языка,
и таким образом только запутывать людей - это вообще какое то днище.
за гранью здравого смысла.

зачем так делать?


по крайней мере с точки зрения рекомендации выше

не очень понятно, о каких таких рекомендациях ты вещаешь.



Тем не менее никто не стал бы тут чего-то "оптимизировать", такая мысль даже не зародилась бы. Просто потому что кроме "расходов памяти" и "скорости" есть еще мощнейший аргумент - расходы на написание кода.

адекватный человек пишет код, который не совершает бессмысленных действий.

адекватный человек понимает:
динамика нужна при решении задач,
когда количество элементов заранее не известно,
или может изменяться в рантайме.

адекватный человек понимает,
что если кол-во элементов фиксированное,
тогда и нет никакого смысла использовать медленную динамику.
можно использовать более быстрое статичное решение.

адекватный человек понимает,
что если по смыслу задачи память необходимо выделить только и только один раз,
тогда нет никакого смысла не только в динамике,
а вообще - нет никакого резона в автоматическом объекте.



и что самое главное:
для того, что бы осознавать столь очевидные вещи,
не нужно быть семи пядей во лбу,
и тратить кучу времени на какие то сложные размышления.

никакая оптимизация здесь не причем.
это - просто здравый смысл.


Зачем же давать рекомендации которым сами не следуем?  Улыбающийся
как я уже писал выше: не очень понятно:
о каких таких рекомендациях ты вещаешь?

Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.06 секунд. Запросов: 22.