Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

StringList & Out of memory [D7, WinXP]

ilkz © (2007-12-27 11:31:00)
Всем доброго времени суток!

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

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

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

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

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

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

Amoeba (2007-12-28 21:36:00) [1]
Если

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

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

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

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

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

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

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

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

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

Сергей М. (2007-12-28 09:05:00) [4]

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

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

sniknik (2007-12-28 08:55:00) [5]
> С учетом приведенной структуры файла это печально.
это точно.

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

Сергей М. (2007-12-28 08:26:00) [6]

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

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

Skyle (2007-12-28 06:44:00) [7]
Скорее всего утечки в разборе строк при заполнении этих самых стринг-листов.

sniknik (2007-12-27 22:46:00) [8]
> Я просил помощи, а не критики.
а холодильник по фотографии не отремонтируете случаем, взаимообразно?

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

Anatoly Podgoretsky (2007-12-27 22:24:00) [9]

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

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

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

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

ilkz (2007-12-27 21:23:00) [10]
П.П.С.: Если есть знатоки, то ДЛЯ НИХ: это формат TBL-файла, описывающего временные диаграммы, генерируемые симулятором из Quartus'а.

ilkz (2007-12-27 21:20:00) [11]
Хм. Вот не надо мне тут Базами тыкать. Моя задача - прочитать и обработать файл данных, который генерируется сторонней программой. А выражения неоптимальный/не экономный обоснуйте, пожалуйста. Я просил помощи, а не критики.

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

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

sniknik (2007-12-27 11:40:00) [12]
все проблемы от 17й строки и неправильной логики программирования автора, ... пока не доказано обратное.

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

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

Сергей М. (2007-12-27 11:34:00) [13]
Парсер у тебя не оптимальный и неэкономный, а возможно и утечки в нем имеются.
Вот и вся сказка.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »