| svale |
| Отправлено: 13.09.2005, 09:06 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 6
|
Дело в следующем.
Прога работает с большим количеством настроек (не интерфейса), на текущий момент порядка 20 тысяч. Настройки читаются один раз при загрузки программы. Проблема в том, что читает очень медленно 30-60 сек. в зависимости от машины.
Существует ли более быстрая альтернатива ини-файлу? (реестр не подходит).
Как вариант XML-файла? Будет ли эффект? |
|
| AVC |
| Отправлено: 13.09.2005, 09:11 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
А вы уверены, что у вас проблема именно в скорости считывания, а не в скорости выполнения считанного ? |
|
| svale |
| Отправлено: 13.09.2005, 09:36 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 6
|
Практически уверен.
Файл разбит на секции примерно по 600 параметров, читается в цикле и распихивается по массивам. На чтение каждой секции уходит примерно по 1,5 секунды. 4 параметра — строки, пятый — целое число. |
|
| Vlad |
| Отправлено: 13.09.2005, 09:48 |
|
Машинист паровоза
Группа: Участник
Сообщений: 231
|
Использовать базу данных, можно в качестве базы — текстовый файл. |
|
| olegenty |
| Отправлено: 13.09.2005, 10:25 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
да, я бы тоже использовал БД. вполне подойдёт DBF + компоенет прямого доступа к DBF (есть на torry)
|
|
| Asher |
| Отправлено: 13.09.2005, 10:32 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
Привет.
а TMemIniFile не пробовали?
|
|
| avc* |
| Отправлено: 13.09.2005, 10:35 |
|
Не зарегистрирован
|
| QUOTE |
Файл разбит на секции примерно по 600 параметров, читается в цикле и распихивается по массивам. На чтение каждой секции уходит примерно по 1,5 секунды. 4 параметра — строки, пятый — целое число
|
А я бы написал свой парсер. Файл может быть текстовым или специального формата (еше быстрее, но тогда нужен редактор). |
|
| svale |
| Отправлено: 13.09.2005, 11:22 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 6
|
Попробовал создать парадоксовскую табличку, доступ стандартными средствами(через Table) — скорость СУПЕР, читается моментально.
olegenty, компонент прямого доступа к DBF — какие преимущества?
Asher, TMemIniFile, в чем преимущество перед Tinifile?
avc*, я думал перекодировать файл каким-то образом в двоичный формат, но сочинять отдельную прогу совсем не хочется.
Наверное остановлюсь на БД, спасибо. |
|
| Asher |
| Отправлено: 13.09.2005, 11:27 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
| QUOTE (svale @ 13/09/2005, 12:22) | Asher, TMemIniFile, в чем преимущество перед Tinifile?
|
А хелп почитать?
| QUOTE | | Unlike the TIniFile object, which also encapsulates INI file data, TMemIniFile buffers all changes to the INI file. The INI file is read once, when the object is first created. Data from the INI file is stored in nested string lists. |
|
|
| olegenty |
| Отправлено: 13.09.2005, 11:27 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
преимущество в том, что если проге даром не нужна работа с БД посредством BDE, то таскать BDE с программой ради загрузки параметров — ну это как-то "даунито синдромо"...
собственно преимущество — прямой доступ к таблице, без посредника в лице BDE.
|
|
| svale |
| Отправлено: 13.09.2005, 11:36 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 6
|
Ага, понятно.
olegenty, а какой компонет не подскажешь? |
|
| Vlad |
| Отправлено: 13.09.2005, 11:59 |
|
Машинист паровоза
Группа: Участник
Сообщений: 231
|
| QUOTE | | Файл разбит на секции примерно по 600 параметров, читается в цикле и распихивается по массивам. На чтение каждой секции уходит примерно по 1,5 секунды. 4 параметра — строки, пятый — целое число.. |
Не заморачивайся, читай как текстовый файл. Один цикл, а быстрее чем fread и разные интерпритации read, ты скорость выше не получишь. Меньше операций -выше скорость, единственно удобство занесения, редактирование параметров |
|
| svale |
| Отправлено: 13.09.2005, 12:11 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 6
|
Остановился на таблице.
Получилось даже лучше чем хотел. И читает быстро, просматривать и заполнять удобнее. |
|
| olegenty |
| Отправлено: 13.09.2005, 12:13 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
см. тут: http://www.torry.net/pages.php?id=564
|
|
| olegenty |
| Отправлено: 13.09.2005, 12:22 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
вот ещё: http://www.activeserverpages.su/redir.asp?...www.majar.nm.ru
|
|
| svale |
| Отправлено: 13.09.2005, 14:28 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 6
|
Спасибо за ссылки, нашел подходящий компонент. |
|
| Sl@Sh |
| Отправлено: 13.09.2005, 17:17 |
|
Мастер участка
Группа: Участник
Сообщений: 383
|
RxFormStorage (кажется он) из RxLibrary может автоматом( только его для этого настроить нужно) сохранть параметры или в ИНИ или в реестр.
|
|
| Rius |
| Отправлено: 15.09.2005, 12:25 |
|
Мастер участка
Группа: Участник
Сообщений: 321
|
самое быстрое — построчный текстовый файл (не ini)
еще и удобное — xml-файл + стандартный TXMLDocument
отдельный компонент, было бы для чего, гы 
|
|
| olegenty |
| Отправлено: 15.09.2005, 12:40 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
ну насчёт быстроты XML..., сдаётся мне, не правда это...
Отредактировано olegenty — 15/09/2005, 13:41
|
|
| AVC |
| Отправлено: 15.09.2005, 12:40 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
>самое быстрое — построчный текстовый файл
Не. Это оптимальное для скорость удобство. А самое быстрое — двоичный файл блоков фиксированного или в крайнем случае известного перед считыванием размера.
Никогда БД не разовьет скорости даже fread. А ведь еще можно и "поизвращаться" с ускорениями. 
Но если автору хватает скорости и удобства БД.... |
|
| Sl@Sh |
| Отправлено: 15.09.2005, 18:51 |
|
Мастер участка
Группа: Участник
Сообщений: 383
|
INI формат оптимален потому, что его может редактировать даже не программист. Если эта возможность вам нужна, то ИНИ лучше всего. Если нет, лучше конечно бинарный файл.
А главное грамотно записывать/читать настройки. Если есть возможность записывать/читать не все сразу то это естественно ускорит процесс.
Грубо говоря вам следует не формат выбирать, а оптимальный метод записи.
Успехов!
Отредактировано Sl@Sh — 15/09/2005, 18:53
|
|
| Rius |
| Отправлено: 16.09.2005, 11:51 |
|
Мастер участка
Группа: Участник
Сообщений: 321
|
редактировать удобно и в XML, но все равно, кому придется править 20000 строк вручную...
для интереса проверил с txmldocument:
- 1млн записей, файл 31МБ, оперы прога жрет 353МБ
скорость, включая файловые операции:
- создание — 1.5 мин, чтение — 18 секунд, если просматривать не все подряд, то быстрее
пример (75кБ):
Отредактировано Rius — 16/09/2005, 14:53
|
|
| AVC |
| Отправлено: 16.09.2005, 13:59 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Для спарвки fwrite (дамп памяти) 31М запись 1.38 сек, чтение 0.07.
Чтение быстрое скорее всего из-за буферизации диска. |
|
| Rius |
| Отправлено: 16.09.2005, 15:04 |
|
Мастер участка
Группа: Участник
Сообщений: 321
|
тут не чтение с диска долгое, а разбор нод в xml-документе., загружает-то также быстро
|
|
| Vlad |
| Отправлено: 16.09.2005, 15:18 |
|
Машинист паровоза
Группа: Участник
Сообщений: 231
|
буферизация — не буферизация, до барабана...по отношению к любым изворотам (библиотекам, компонентам...) fread and fwrite будут быстрее . одна — библиотечная функция или куча , которых нужно обработать, и которые на нижнем уровне опятьто таки используют fread. Просто пусть выбирает человек, скорость (если критично) — fread , удобство — база данных или xml. |
|
| ** Admin |
| Отправлено: 16.09.2005, 20:07 |
|
Не зарегистрирован
|
Если скорость работы с таблицей БД устраивает — останавливайтесь
на ней.
Минусы -
1. если соберетесь ставить/переносить на разные компьютеры
придеться тащить-ставить BDE — а это тоже не есть хорошо.
2. Скорость все равно ниже чем при работе с бинарным файлом.
3. При многопользовательской работе с таблицей начнуться глюки.
Поставите какое-нибудь левое приложение на компьютер,
оно может при установке неверно перезаписать ваше BDE,
начнется куча глюков — то есть вы будете всегда привязаны к BDE
(или к его аналогу). Или без BDE, с компонентом прямого доступа:
Допустим выйдет C++Builder 7..8..9..10..11..12..
а компонент прямого доступа автор под него не переделает,
все, попали — перейти с этой прогой на новый C++Builder не удастся.
Бинарный файл — более универсальное решение.
Во-первых — скорость работы значительно выше,
во-вторых нет зависимости от BDE или компонентов прямого доступа,
значит программа более переносима.
А оформить работу с этим файлом — удобно в виде класса
с методами чтения/записи.
|
|
| olegenty |
| Отправлено: 17.09.2005, 06:52 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
насчёт компонента — убедили, лучше свой написать
|
|
| Rius |
| Отправлено: 17.09.2005, 07:22 |
|
Мастер участка
Группа: Участник
Сообщений: 321
|
Admin так BDE не единственный, тот же Jet OLEDB + *.mdb везде будет работать без необходимости что-либо доустанавливать.
|
|
| Георгий |
| Отправлено: 18.09.2005, 01:03 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
| QUOTE (Rius @ 17/09/2005, 08:22) | | Admin так BDE не единственный, тот же Jet OLEDB + *.mdb везде будет работать без необходимости что-либо доустанавливать. |
не будет — если драйвера БД (dll) не стоят, но не будет работать |
|
| Rius |
| Отправлено: 19.09.2005, 05:36 |
|
Мастер участка
Группа: Участник
Сообщений: 321
|
в чистой свеженькой windows xp все необходимое для mdb уже есть, на других чистых системах не проверял к сожалению, но при наличии MS Office все должно работать 100%.
|
|
