Минимизация = уменьшение размера проги в памяти?

← →
lexxx (2004-08-25 11:12) [0]

Такая ситуация, у меня при своей работе программа открывает сотни потоков паралельной обработки информации, юзаю TThread. В главном окне проги показывается различная статистика по работе потоков, размер проги в памяти при открытом окне приложения растет до 90 мегов, как только минимизирую прогу в панель задач, то потоки работают дальше без каких либо проблем но размер проги в памяти становится 20 мегов, вопрос такой, а что собственно происходит в остальных 70 метрах памяти когда окно не свернуто? В главном окне проги расположены 10 эдитбоксов куда методами synchronize отображается статистика обработки инфы и всё, что является причиной такого разрастания?. Не пойму в чем дело.

← →
KSergey © (2004-08-25 11:18) [1]

> программа открывает сотни потоков паралельной обработки
> информации

А вы уверены, что это гут?

А по основному вопросу - не берите в голову. Считайте, что так и надо.

← →
lexxx (2004-08-25 11:22) [2]

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

← →
lexxx (2004-08-25 11:33) [3]

Причем заметил если я минимизировал окно то память высвободилась до 20 метров и потом снова начала расти уже в минимизированном виде до своего наибольшего объема, тогда развернул окно снова и свернул, снова размер проги уменьшился до 20 метров. Я чего то не догоняю. Люди помогите пжалста

← →
Digitman © (2004-08-25 11:33) [4]

> lexxx (25.08.04 11:22) [2]

> надо же разобраться, каким образом эта память высвобождается
> и что в ней хранилось кроме самого окна приложения

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

имей ввиду, что при использовании TThread каждый созданный трэд "отнимает" в ВАП тек.процесса не меньше чем от MinStackSize до MaxStackSize байт вирт.памяти

← →
KSergey © (2004-08-25 11:34) [5]

Считайте, что диспетчер программ показывает неверные результаты. Вернее, отражающие совсем не то, о чем вы подумали.

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

Характерно, что в каждом случае речь идет именно о просмотре через диспетчер программ.
Когда-то Игорь шевченко что-то вроде объяснял (год или два назад), но я не запомнил ничего кроме того, что это не должно волновать простых смертных. Что это совсем не то, что мы думали и ничего эти цифири реально не отражают.

Только и ему, понятно, на такие вопросы прискучило отвечать.

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

← →
KSergey © (2004-08-25 11:35) [6]

> [5] KSergey © (25.08.04 11:34)
> Когда-то Игорь шевченко

Приношу извинения
Игорь Шевченко

← →
lexxx (2004-08-25 11:38) [7]

понял вас. да вы правы, я через диспетчер смотрю. Спасибо.
а трединг мне понадобился для обработки ну очень большого объема инфы. при 20 потоках скорость обработки намного медленней чем при пары сотни. озу 4 гига, четыре ксеона, думаю этого достаточно для такого числа потоков

← →
KSergey © (2004-08-25 11:41) [8]

> при 20 потоках скорость обработки намного медленней чем
> при пары сотни

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

← →
TUser © (2004-08-25 11:44) [9]

Такое кол-во потоков может понадобиться разве что на крутом сервере для обслуживания соотв. кол-ва клиентов.

← →
Romkin © (2004-08-25 12:23) [10]

lexxx (25.08.04 11:38) [7] Тогда уж лучше на процессы разбивать. Ты потоки к процессорам привязываешь?

← →
Digitman © (2004-08-25 12:32) [11]

> трединг мне понадобился для обработки ну очень большого
> объема инфы

что есть у тебя "обработка" ?
кто и каким образом передает трэдам данные для обработки ?
хотя бы в 2-х словах поясни ...

← →
lexxx (2004-08-25 13:32) [12]

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

← →
lexxx (2004-08-25 13:34) [13]

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

← →
lexxx (2004-08-25 13:35) [14]

сорри опечатался, 90 мегов

> lexxx

я так и не понял, ЗАЧЕМ тебе доп.трэды ?

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

> lexxx

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

но у тебя же о транспорте речи не идет ! обработке у тебя подвергаются УЖЕ целиком доставленные (неважно как) данные !
так ну и обрабатывай ты их одним-единственным осн.трэдом в цикле ! какие проблемы-то ?

← →
Slym (2004-08-25 14:18) [17]

У тебя 4 процессора... делай 4 потока. Быстрее всеравно не получишь: затраты на переключение потоков, синхронизацию убьют твою поточность.

Ты говоришь быстрее 100 потоков чем 4 :) дык это потому что при одинаковых приоритетах вероятность выбрать 1твой из (100 твоих +100 системных) выше чем 1твой из (4 твоих +100 системных)
Ставь приоритет потоков повыше

А про память:
В момент сворачивания главного окна система сбрасывает всю память проги в своп очищая оперативку...
Прога работает, требует данные сброшенные в своп, система вытаскивает их в оперативку... и так до тех пор пока все данные в свопе не забьют оперативку

← →
lexxx (2004-08-25 19:11) [19]

=) спасибо всем за советы, одно слово цикл меня пугает, потому что если сервак повиснет изза какойнить ошибки в одном файле, то считай ночь обработки потеряна, а тут время деньги, а с потокмаи не страшно, встанет один и бог с ним остальные три дело доделают %)
сделал приоритет повыше и 4 потока тож не плохо пашут, но вот размер конечно все равно растет в памяти, Slym спасибо тебе отдельное, я чегото не догадался и не подумал про своп, ведь это действительно именно туда память сливается и фактически прога меньше размером не становится.

Не только это, система может освободить ассоциированые ресурсы, которые она на всякий случай держит, выбросить не нужные ДЛЛ, которые также закешированы на всякий случай.

Минимизация = уменьшение размера проги в памяти? Найти похожие ветки