Как побороть EOutOfMemory ?

← →
val_5 © (2004-05-05 22:16) [0]

Как побороть EOutOfMemory ?
Увеличить файл подкачки в ОС. Или в Project_Options.Linker увеличить стэк. Или еще как ?

← →
Gero © (2004-05-05 22:17) [1]

Купить больше оперативки.

← →
Algol (2004-05-05 22:20) [2]

> Как побороть EOutOfMemory ?

Оптимизировать алгоритм работы с данными ;)

← →
tesseract © (2004-05-06 17:17) [3]

Поскать утечки памяти в программе. Если это БД то всё ясно - такая прорва таблиц в памяти висеть остаётся.

Так-что если это твой случай не вырубайся в дельфу по f2 - проверено, помогает.

← →
val_5 © (2004-05-06 21:43) [4]

To tesseract:
Что может означать фраза "не вырубайся в дельфу по f2" ?

To All:
Ошибка происходит при SetLength(Arr, Length(Arr) + 1). На этот момент в массиве уже порядка 700000 элементов. Массив двумерный, элемент массива это record ~70байт. Вообще идет работа с несколькими массивами. Поставил размер файла подкачки 4Гб, оперативки 500Мб. Но во время выполнения в диспетчере задач видно что программа использует менее 200Мб памяти, есть запас оперативки и виртуальной памяти - но происходит вылет по EOutOfMemory ?! Почему ОС не выделяет память до упора ? ( На испытательном сроке дали внедрять это гавно(до меня это лепили 5 человек и бросали) Вообще это расчет оптимальных маршрутов развозки заказов. Утечек памяти нет, просто просчитывается такое огромное количество вариантов развозки)

← →
Vlad © (2004-05-06 21:53) [5]

> val_5 © (06.05.04 21:43) [4]

Может Packed Record спасет ? Или использование TList вместо массива.

← →
Palladin © (2004-05-06 21:53) [6]

какой то неоптимальный расчет оптимальных маршрутов

пилите шура пилите :)

← →
Palladin © (2004-05-06 21:55) [7]

> Vlad © (06.05.04 21:53) [5]

TList сам использует динмассив... так что к 70 байтам прибавится еще 4, а Packed Record скажется на производительности...
тут принцип работы с данными менять надо...

← →
Vlad © (2004-05-06 22:01) [8]

Да, лучше конечно менять принцип.
Я не знаю что за задача такая, но судя по всему там должна использоваться БД, так что есть ли смысл использовать массивы, может проще SQL запросами все вычисления производить ?

← →
Vlad © (2004-05-06 22:08) [9]

> Palladin © (06.05.04 21:55) [7]

Кстати, сейчас глянул, а TList вроде статический массив использует

← →
panov © (2004-05-06 22:17) [10]

Попробуй работать с FileMapping. Возможно поможет.

← →
Palladin © (2004-05-06 22:20) [11]

Он использует ^array[0.. ] of и естественно происходит reallocmem при вставке элемента, практически тоже что и динмассив, только без счетчика ссылок. Те же принципы.

← →
val_5 © (2004-05-06 23:30) [12]

Можно провести эксперимент - в бесконечном цикле наращивать динамический массив. EOutOfMemory выскочит ТОЛЬКО тогда когда будет использован весь файл подкачки. Это видно в диспетчере задач. В той же программе EOutOfMemory происходит когда есть место в файле подкачки и даже метров 150 в физической памяти. Если устранить причину почему ОС не выделяет имеющуюся память - проблема будет решена.

← →
Mim1 © (2004-05-07 00:08) [13]

val_5 © (06.05.04 23:30) [12]

ИМХО Система не выделяет достаточно пямти по той причине, что размер свободной памяти меньше размера требуемой. То есть если свободно 400мб а требуется 500 системе совсем не обязательно занимать 400 для того чтобы ругнуться.

Я бы вампосоветовал, вместо массива, воспользоваться списком элементов, ссылающихся друг на друга. При этом элементы будут разбросаны хаотично, а не ввиде одного большого куска памяти, и добавление нового элемента не будет требовать наличия места для данного куска + 1 (или места для нового элемента поле текщего куска).

← →
Algol (2004-05-07 00:09) [14]

> val_5 © (06.05.04 23:30) [12]

Да я тебе и так могу сказать причину:
Когда ты вызываешь вот это SetLength(Arr, Length(Arr) + 1), у тебя происходит не просто добавление одного элемента к массиву, а ВЕСЬ массив перемещается в другую область памяти, при чем под массив резервируется в два раза больше места чем его актуальная длина. Из-за этого расход памяти и происходит ))
Если хочешь использовать динамический массив, т старайся хотя бы заранее определить его размеры, будет работать намного эффективней.

← →
Mim1 © (2004-05-07 00:09) [15]

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

← →
Algol (2004-05-07 00:21) [16]

Algol (07.05.04 00:21) [16]

Можно еще с бинарными деревьями пиограться.

← →
Algol (2004-05-07 00:43) [18]

> Можно еще с бинарными деревьями пиограться.

Ну для высокопроизводительных систем это наверно единственное решение и есть. (Только не обязательно бинарные, в n-арных скорость доступа выше).
Хотя, конечно, массив все равно быстрей.

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

Algol (07.05.04 00:43) [18]

ИМХО хоть скорость доступа в массиве и выше чаше всего n"ный элемент смысловой нагрузке не несет, то есть для работы нам требуется не элемент с определенным порядковым номером а элемент имеющий определенные аттрибуты. При таком подходе в активно используются циклы и т.п. Так что ситуация со списком равносильна массиву, а ситуация с доревом как раз и даст реальный прирост в производительности.
Однако пререход от массива к списку не совсем легкая задача, придется несколько изменить свою логику.

>Паниковский © (07.05.04 06:31) [19]
>может не используюмую часть на диск выгрузить а потом опять подкачать?

угу, насосом для велосипеда! ;-)

← →
Algol (2004-05-07 09:53) [22]

> может не используюмую часть на диск выгрузить а потом опять
> подкачать?

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

Как побороть EOutOfMemory ? Найти похожие ветки