StringList & Out of memory

← →
ilkz (2007-12-27 11:31) [0]

Всем доброго времени суток!

Возникла тут такая проблемка. Есть структура типа record, у которой приличное количество полей, большая часть из которых - динамические массивы.

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

Проблема в парсере. Пока размеры загружаемых файлов не достигают порядков нескольких десятков мегабайт: в таких случаях вылетает ошибка Out of Memory. Вся обрабатываемая информация хранится в StringList"ах, коих тоже может быть заранее неизвестно сколько и какого размера.

Вопрос, собственно, заключается в том, чтобы понять причину - откуда возникает эта ошибка? Судя по диспетчеру задач, прога при обработке больших фалов занимает более ПОЛУТОРА ГИГОВ оперативки... По-моему, тут что-то не так...
П.С.: Все СтрингЛисты после работы с ними обязательно уничтожаются (.free).

П.С: компы, на которых прога работает - 3.2ГГц/1Гб ОЗУ; 3.2ГГц 64 бит/2Гб ОЗУ, так что с памятью проблем нет.

Спасибо за помощь!

← →
Сергей М. © (2007-12-27 11:34) [1]

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

← →
sniknik © (2007-12-27 11:40) [2]

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

а тут не то что доказательства, вообще полезной инфы не приведено...

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

← →
ilkz (2007-12-27 21:20) [3]

Хм. Вот не надо мне тут Базами тыкать. Моя задача - прочитать и обработать файл данных, который генерируется сторонней программой. А выражения неоптимальный/не экономный обоснуйте, пожалуйста. Я просил помощи, а не критики.

P.S.:
Вот примерная структура обрабатываемых строк:
>123.456 123 123 AF3 = X 123 456 UUU AB3 -100
>123.456 123 123 AF3 = X 123 456 UUU AB3 -100
.............................................
.............................................
.............................................
>123.456 123 123 AF3 = X 123 456 UUU AB3 -100
>123.456 123 123 AF3 = X 123 456 UUU AB3 -100

Таких строк может быть несколько СОТЕН тысяч, и не от меня зависит то, что они хранятся в текстовом файле. Более того, колонок может быть также до нескольких десятков.

← →
ilkz (2007-12-27 21:23) [4]

П.П.С.: Если есть знатоки, то ДЛЯ НИХ: это формат TBL-файла, описывающего временные диаграммы, генерируемые симулятором из Quartus"а.

← →
Anatoly Podgoretsky © (2007-12-27 22:24) [5]

> Если есть знатоки,

Все равно, то что ниже.

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

Плюс ошибка в 17 строке.
Если ты не можешь разобраться со своим кодом, то что делать телепатам без него?

← →
sniknik © (2007-12-27 22:46) [6]

> Я просил помощи, а не критики.
а холодильник по фотографии не отремонтируете случаем, взаимообразно?

> Вот примерная структура обрабатываемых строк:
хорошая структура... если там все так, то действительно с базами я ошибся чуток.
тут нужен только счетчик на "несколько СОТЕН тысяч"(одной int. переменной хватит) и данные одной строки, все остальное мусор, т.к. повторяются.
и так наверное для каждого массива. (какая оптимизация а?! с логикой разобрались, осталась 17я строка...)

← →
Skyle © (2007-12-28 06:44) [7]

Скорее всего утечки в разборе строк при заполнении этих самых стринг-листов.

← →
Сергей М. © (2007-12-28 08:26) [8]

> выражения неоптимальный/не экономный обоснуйте

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

← →
sniknik © (2007-12-28 08:55) [9]

> С учетом приведенной структуры файла это печально.
это точно.

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

> sniknik © (28.12.07 08:55) [9]

Можно и традиционным для таких задач (парсинга, имеется ввиду) regexpr-движком обойтись. Городить огород с собственным парсингом при таких навскидку тривиальных условиях нет никакого резона.

← →
Правльный_Вася (2007-12-28 10:25) [11]

> Вот не надо мне тут Базами тыкать. Моя задача - прочитать
> и обработать файл данных

читать можно построчно
а для обработки складывать в промежуточные таблицы БД, а не какие-то левые рекорды с динамическими массивами

← →
Sapersky (2007-12-28 20:33) [12]

Есть структура типа record, у которой приличное количество полей, большая часть из которых - динамические массивы.
[...]
Пока размеры загружаемых файлов не достигают порядков нескольких десятков мегабайт: в таких случаях вылетает ошибка Out of Memory.

SetLength(Array, Length(Array)+1)?

Если

> Таких строк может быть несколько СОТЕН тысяч

+ несколько СОТЕН тысяч выполняется такое: SetLength(Array, Length(Array)+1)
то известный результат будет налицо.

Похоже, что телепатор у
> Sapersky (28.12.07 20:33) [12]

сработал. Будем ждать автора вопроса.

StringList &amp; Out of memory Найти похожие ветки

StringList & Out of memory Найти похожие ветки