Сработало исключение EOutOfMemory: как оптимизировать память?

← →
Стенка (2009-10-12 14:49) [40]

Ты победил

← →
Kolan © (2009-10-12 14:55) [41]

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

← →
Стенка (2009-10-12 14:59) [42]

Как страшно жить. Все мои программы на него полагаются.

← →
Inovet © (2009-10-12 15:06) [43]

> [34] yantux © (12.10.09 14:42)
> а если так?

См

> [41] Kolan © (12.10.09 14:55)
> Менеджер памяти сложная штука, разобраться в ней не так
> уж и просто. Более того, алгоритмы запросто могут измениться.
> Поэтому полагаться на его особенности опасно.

Ну допустим, что 2 * 5000000 не сразу отдаст ОС,
1. не факт что они расположены последовательно
2. после SetLength в 0 в эти куски что-то не прописалось тобой же самим.

← →
Inovet © (2009-10-12 15:09) [44]

> [42] Стенка (12.10.09 14:59)
> Как страшно жить. Все мои программы на него полагаются.

> [41] Kolan © (12.10.09 14:55)
> на его особенности

← →
Стенка (2009-10-12 15:20) [45]

> Inovet © (12.10.09 15:09) [44]

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

← →
Сергей М. © (2009-10-12 15:25) [46]

> будет ли МП использовать загашник два блока по 500000?

Не будет.
Этих блоков попросту нет - ты вернел назад не два по 500000, а два по 499999 элементов.

А даже если бы и вернул два по 500000, то не факт что они расположены последовательно, что при запросе 1000000 элементов позволило бы менеджеру объединить их в один непрерывный блок.

Да и не может этот код привести EOutOfMemory/

← →
yantux © (2009-10-12 15:40) [47]

> Менеджер памяти сложная штука, разобраться в ней не так уж и просто. > Более того, алгоритмы запросто могут измениться. Поэтому полагаться на > его особенности опасно.

Да, но он придуман, чтобы упрощать работу программиста. В этом его полезное свойство. Тогда почему на него нельзя положиться?

← →
yantux © (2009-10-12 15:41) [48]

> А то, что чел дефрагментирует память, не возвращая все взятое, это особенность чела.

Ни чего я не дефрагментирую, я даже не знаю, как это делать. Это java дефрагментирует, но программисту даже не надо об этом знать.

← →
yantux © (2009-10-12 15:44) [49]

> Ну допустим, что 2 * 5000000 не сразу отдаст ОС,
> 1. не факт что они расположены последовательно
> 2. после SetLength в 0 в эти куски что-то не прописалось тобой же самим.

Можно ли менеджер памяти заставить сразу отдавать ОС, чтобы он делал это автоматически?

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

← →
sniknik © (2009-10-12 15:46) [50]

> Я не ищу утечек, поскольку я не использую malloc, new.
ну и дура... (© Джентльмены удачи), какая разница как ты накрасишься, если под видом бабы все одно мужик?
...
procedure NotMalloc(...)
begin
... malloc(...)
end;

невозможная ситуация? а ты ВЕСЬ используемый код, не свой, а то что в нем используется, изучил... ну, ну.

>> Ответить на этот вопрос без кода НЕВОЗМОЖНО.
> var
> a, b : array of integer; (* создаю безразмерный массив *)
ты кого обманываешь? сам себя... работа с массивом чисел и массивом рекордов (про которые речь в начале), очень сильно различается.

← →
Kolan © (2009-10-12 15:47) [51]

Я, лично, считаю, что не надо наедятся на то, что у менеджера памяти что-то останется или не останется в загашнике.

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

Еще я думаю, с учетом: «растровые фотки их обработка», что для сабжа вообще не нужно выделять всю память сразу, а можно подгружать фотки и удалять ненужные (не видимые?) по мере надобности.

← →
Kolan © (2009-10-12 15:49) [52]

Кстати, даже если менеджер памяти отдаст её ОС, то это не значит, что она станет доступна для других процессов.

← →
Стенка (2009-10-12 15:58) [53]

> А то, что чел дефрагментирует память, не возвращая все взятое, это особенность чела.

фрагментирует

← →
Inovet © (2009-10-12 16:00) [54]

> [49] yantux © (12.10.09 15:44)
> 2. в этом случае устойчиво срабатывает исключение на проверку
> выхода за границе массива, соответсвующую галочку поставил
> в опциях компилятора

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

выделение;
try
что-то делаешь;
finally
освобождение;

← →
Dennis I. Komarov © (2009-10-12 16:52) [55]

Во человек - пол сотни постов, а показать что в массиве...
Боюсь стенка лба не выдержит...

← →
Стенка (2009-10-12 19:49) [56]

Уже не выдержала. Лоб оказался крепче.

← →
brother © (2009-10-13 04:36) [57]

я ему еще в [12] все ответил...

← →
MonoLife © (2009-10-13 06:50) [58]

yantux © (12.10.09 10:51) [7]

> но как описана a ?

record

yantux © (12.10.09 10:54) [10]

> или мы должны гдать размер одного элемента... ибо 100 непонятно чего жрет 240 мб оперативы?

растровые фотки их обработка

что-то я не увидел у автора сабжа где и как загружаются и освобождаются в record "фотки".. всё про массив integer твердит.. ей богу, "партизанен"))
С логикой проектирования тоже как-то подозрительно, как сказал Kolan © (12.10.09 15:47) [51]

← →
yantux © (2009-10-13 10:34) [59]

> ты кого обманываешь? сам себя... работа с массивом чисел и массивом >рекордов (про которые речь в начале), очень сильно различается.

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

>Длину ты изменил до 0, но ты пользуешься библиотекой и если не сам >явно, то откуда гарантия, что в ней не произошло фрагментации. Да и >вообще что за фобия выделять и освобождать по человечески.
>
>выделение;
>try
> что-то делаешь;
>finally
> освобождение;

Можно и так, но почему не ползоваться setlength() ? Чем он хуже?

>Я, персонально, думаю, что выделять массивы размером в несколько >миллионов элементов нужно очень редко, почти никогда.
>
>Еще я думаю, с учетом: «растровые фотки их обработка», что для сабжа >вообще не нужно выделять всю память сразу, а можно подгружать фотки и >удалять ненужные (не видимые?) по мере надобности.

Не охота тратить время на ввод/вывод, тем более, если это тормозная флешка или cd. Загрузил, обработал, сохранил - так быстрее.

>Кстати, даже если менеджер памяти отдаст её ОС, то это не значит, что >она станет доступна для других процессов.
Это уже не касается моей программы, это проблема ОС.

← →
Inovet © (2009-10-13 10:40) [60]

> [59] yantux © (13.10.09 10:34)
> >выделение;
> >try
> > что-то делаешь;
> >finally
> > освобождение;
>
> Можно и так, но почему не ползоваться setlength() ? Чем
> он хуже?

Хотя бы потому, что одно дело функция, и другое механизм языка.

← →
Inovet © (2009-10-13 10:42) [61]

> [59] yantux © (13.10.09 10:34)
> > ты кого обманываешь? сам себя... работа с массивом чисел
> и массивом >рекордов (про которые речь в начале), очень
> сильно различается.
>
> Со своей точки зрения программиста не вижу разницы, т.е.
> я надеюсь что эти отличия изолированы от меня.

Ты хочешь, чтоб тебе указали на ошибку не видя эту рекорд?

← →
sniknik © (2009-10-13 10:58) [62]

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

в компилируемых не так, там часто НЕВОЗМОЖНО отследить чего и где на-создал программист (есть ссылки, указатели, есть передачи по не типизированным указателям, где только программист и может знать что по ним "лежит"), в общем если ты на-создавал в своих рекордах каких то объектов, ссылок, а после освобождаеш только "внешнее", то "внутреннее" за тебя компилятор освобождать даже не попытается... (мало ли где ты на эти объекты еще ссылаешься), изолировать это от ПРОГРАММИСТА можно только запретив... если тебе это не нравится то ВАЛИ с дельфи, это не твое...

> это проблема ОС.
виноваты все кроме тебя естественно, это так по ламерски...

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

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

Я прекрасно это понимаю, поэтому не испоьзую указателей, объектов и прочее в нутри рекода.

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

т.е. если я использую setlength, то менеджер памяти будет всё грести под себя, а если я буду использовать new, dispose, то я смогу освобождать память и честно возвращать ОС? Но если идти таким путём, то как снежный ком в С++ начнуть плодиться ошибки утечки памяти. Хотелось бы этого избежать.

Можно ли турнуть менеджер памяти, что бы после setlength(z,0) он возвращал всю память ОС?

> т.е. если я использую setlength, то менеджер памяти будет
> всё грести под себя, а если я буду использовать new, dispose,
> то я смогу освобождать память и честно возвращать ОС?

Смотря как использовать.
Пример. Вот ты выделил мегабайтный массив, и сразу за ним что-то положил менеджер. Занято — метр с лишним.
Далее ты задал массиву длину 0. Получилась метровая дыра в памяти, управляемой менеджером. Занято — опять же метр с лишним.
Если сразу же задать массиву прежнюю длину, он разместится в том же месте, и памяти займётся не больше прежнего. Если хоть на байт больше — поимеем уже два с лишним метра занятой памяти. Если менеджер перед этим успел что-то ещё разместить в свободном месте — в него не поместится и прежний мегабайтный массив.
Если размещаешь/освобождаешь в куче сам, то избегаешь таких ситуаций.

> о если идти таким путём, то как снежный ком в С++ начнуть
> плодиться ошибки утечки памяти

Утечки в С++ плодятся не просто из-за ручного выделения/освобождения, это чересчур просто (хотя и бывает), а из-за того, что оно хитро прячется за перегрузками операторов, передачами по ссылке, копированию объектов и ещё тысяче мелочей; в общем — из-за злоупотреблением чрезмерной сложностью языка.

> Я прекрасно это понимаю, поэтому не испоьзую указателей, объектов и прочее в нутри рекода.
и думаешь исходя из твоего понимания компилятор будет работать по другому? а переключатель у него телапатический, для тех кто понимает и использует один код, понимает и не использует другой, не понимает но использует третий и т.д. ... смешно.

> Можно ли турнуть менеджер памяти, что бы после setlength(z,0) он возвращал всю память ОС?
повторение мать учения... можно, но партизанам это не нужно.

> Я прекрасно это понимаю, поэтому не испоьзую указателей,
> объектов и прочее в нутри рекода.

Вретес ведь, Штирлиц....

> Вретес ведь, Штирлиц....

Разве Штирлиц был сантехником?

> Разве Штирлиц был сантехником?

он был разведчиком) как и автор)

> Можно ли турнуть менеджер памяти, что бы после setlength(z,
> 0) он возвращал всю память ОС?

Finalize(z)

> Finalize(z)

спасибо

Сработало исключение EOutOfMemory: как оптимизировать память? Найти похожие ветки