Ускорение работы программы

← →
Alex_C © (2007-06-14 16:50) [0]

Модернизирую одну старую программу:
она при выборе сотрудника из обычного текстового файла брала для него данные. Делалось это просто ReadLn - считывались строки начиная от начала (фаил не сортированный), и когда находилась нужная фамилия - строка с данными из файла выводилась на форму.
Т.к. текстовый фаил маленький - около 200к решил при загрузке проги его полностью считывать в память (array of String) и уже работать с этим массивом. Думал, что скорость увеличиться - но толи современные компы так быстро работают с диском, то ли еще что - скорость не увеличилась (покрайней мере визуально).
Вопрос: стоит ли так модернизировать программу? Ведь лишняя память (хоть и не много), но расходуется.

← →
Johnmen © (2007-06-14 16:53) [1]

Читать из файла надо сразу всё одним блоком, а не кусочками по строке.
Используй TStringList.

← →
Alex_C © (2007-06-14 17:01) [2]

То Johnmen: для информации - может я что-то не так делал, но StringList.LoadFromFile работает на несколько порядков медленнее ReadLN. Причина по видимому в том, что после чтения, StringList еще какие-то процедуры выволняет.
В общем от StringList отказался - медленнее значительно.
Да и не в этом вопрос! Я спрашиваю - перед началом работы стоит весь фаил в память грузить или нет? Ведь по времени работы разницы на глаз не видно.

← →
Johnmen © (2007-06-14 17:04) [3]

> Я спрашиваю - перед началом работы стоит весь фаил в память
> грузить или нет?

Смотря в чём заключается обработка.
ЗЫ
Прочитать можно BlockRead"ом сразу всё...

← →
SpellCaster (2007-06-14 17:06) [4]

Попробуй читать в буфер, а потом искать в нем ye;ye. фамилию процедурой AnsiPosStr

← →
Dimaxx © (2007-06-14 17:13) [5]

> для информации - может я что-то не так делал, но StringList.
> LoadFromFile работает на несколько порядков медленнее ReadLN.
>

А как ты использовал? LoadFromFile читает сразу весь файл в список и хранится он там до уничтожения. Далее через TStringList.IndexOf ищем нужную строку (функция вернет индекс в списке). Если в строке несколько параметров - используй AnsiPos для поиска вхождения нужной части строки. Это будет всяко быстрее построчного считывания файла.

← →
Alex_C © (2007-06-14 19:16) [6]

> Это будет всяко быстрее построчного считывания файла.

Тоже так думал. Ан нет! Считывал все в TSringList - работать с ним на порядок медленнее. Сам был весьма удивлен. Можешь сам попробовать. :)

← →
SpellCaster (2007-06-14 20:30) [7]

> Тоже так думал. Ан нет! Считывал все в TSringList - работать
> с ним на порядок медленнее. Сам был весьма удивлен. Можешь
> сам попробовать. :)

Потому что IndexOf в случае несортированного списка просматривает весь массив тупым перебором. Юзай [4], быстрее вряд ли что-то можно выдумать. Если только еще заюзать оптимизированную процедуру поиска подстроки (например, из пакета AcedUtils)

← →
Arm79 © (2007-06-14 21:47) [8]

> SpellCaster (14.06.07 20:30) [7]
> > Тоже так думал. Ан нет! Считывал все в TSringList - работать
>
> > с ним на порядок медленнее. Сам был весьма удивлен. Можешь
>
> > сам попробовать. :)
>
> Потому что IndexOf в случае несортированного списка просматривает
> весь массив тупым перебором. Юзай [4], быстрее вряд ли что-
> то можно выдумать. Если только еще заюзать оптимизированную
> процедуру поиска подстроки (например, из пакета AcedUtils)

А что мешает отсортировать список?

← →
homm © (2007-06-14 22:34) [9]

> Думал, что скорость увеличиться - но толи современные компы
> так быстро работают с диском, то ли еще что - скорость не
> увеличилась (покрайней мере визуально).

При чтенмм первого же блока весь файл одной операцие чиения помещаеться в кеш жесткого диска, откуда уже блоками помельче перекачевывает в кеш операционной системы. Так что файл 200Кб — это не работа с жестким диском.

← →
Johnmen © (2007-06-14 23:20) [10]

> При чтенмм первого же блока весь файл одной операцие чиения
> помещаеться в кеш жесткого диска,

Ты уверен? М.б. все-таки сектор, а не "весь файл"?

← →
homm © (2007-06-14 23:37) [11]

> Ты уверен? М.б. все-таки сектор, а не "весь файл"?

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

← →
SlymRO © (2007-06-15 06:34) [12]

Под рукой дельфи нет, но на память:
TMemIni (inifiles.pas) пользует THashList гляди в том направлении

← →
SpellCaster (2007-06-15 10:56) [13]

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

← →
Arm79 © (2007-06-15 16:42) [14]

> SpellCaster (15.06.07 10:56) [13]
> > А что мешает отсортировать список?
> Предположим, есть большая группа детей, и надо найти ребенка
> с определенным ростом. Что легче - измерить рост у каждого,
> или же вначале выстроить их по ранжиру, а потом методом
> двоичного поиска найти нужного ребенка, учитывая, что все
> операции по сравнению и "перемещению" придется делать самому?
>

1) Рост не является уникальным ключом, соответственно при попытке найти ребенка по определенному росту, может выдаться несколько значений, в таком случае есть смысл в предварительном ранжировании

2) Смысл в предварительном ранжировании будет если поиск по росту будет многократным, тогда потери времени на предварителную обработку будут скомпенсированы скоростью поиска

← →
SpellCaster (2007-06-15 17:25) [15]

> [14] Arm79 © (15.06.07 16:42)

Возвращаемся к началу и смотрим задачу:
ReadLn - считывались строки начиная от начала (фаил не сортированный), и когда находилась нужная фамилия - строка с данными из файла выводилась на форму.

то есть
1) значение уникально
2) поиск производится 1 раз

А откуда вы взяли, что поиск проводится только раз? Я вот вычитал там, что конкретный сотрудник находится только раз, но сколько раз ищутся сотрудникИ - не указано. Что то не верится мне, что та программа каждый раз запускалась только для работы с ОДНИМ сотрудником... Значит несмотря на уникальность, вполне может быть второй случай - многократный поиск сотрудников.

И вообще, мы отклонились от темы, автор спрашивал, стоит ли заморачиваться с модернизацией программы если на глаз отличий по скорости нет. Я считаю что не стоит.

PS А факт увеличения расходуемой памяти на целых 200кб по моему перестал иметь какое либо значение еще лет 7 назад.

То Arm79: ты совершенно прав. Конечно сотрудники ищутся много, я бы даже сказал ОЧЕНЬ много раз! По этому и вопрос такой был.
И еще сейчас все попробвал: с одной строны увеличение на 200к - это сейчас вообще капля в море. С другой - как очень верно было сказано ReadLN в досе (где за раз считывалась только 1 строка) и сейчас - две большие разницы. Сейчас при обращении к диску данные с него считываются с запасом.
Итог для себя сделал такой: заморачиваться можно, но толку нет :)

> Сейчас при обращении к диску данные с него считываются с
> запасом.

Так было всегда. Ещё во времена ДОСа первой версии...:)

> Так было всегда. Ещё во времена ДОСа первой версии...:)

Однако разница при чтении из файла ReadLN и ReadBlock были в разы...

> Однако разница при чтении из файла ReadLN и ReadBlock были в разы...

Хм... BlockRead м.б.? Так можно сделать, что будут одинаковы. Если размер блока примерно = длине строки...

Ускорение работы программы Найти похожие ветки