TIniFiles vs TStringList

← →
Пробегал... (2008-03-02 19:02) [0]

Кто-нибудь знает, что будет быстрее работать - выборка/запись параметра в TIniFile или в TStringList.Values ? И сильно ли будет различаться скорость?

Дело вот в чем. У меня в программе будет файл настроек. Возможно, он будет очень большой, я уже упирался одно время в достаточно медленную скорость работы TIniFile на большом количестве параметров. Базу данных пока прикручивать не хочется. Вот я думаю - даст ли выигрыш в производительности такой вариант:

все настройки считываются вручную в StringList, в программе с ними происходит работа.

Сохраняется все в файл настроек через TIniFile. Почему? Хочется разбиение по секциям, чтобы в текстовом редакторе тоже было удобно смотреть / редактировать файл настроек. А это или упорядочивать StringList надо перед сохранением, либо тупо воспользоваться TIniFile ;)

Сохранение может быть будет делаться и после каждого изменения параметра (чтобы не потерять данные в случае краха программы), но в реальности расчитывают на выигрыш, что сохранение будет делаться после группового изменения параметров. То есть, кто-то что-то там настроил допустим в диалоге, группа параметров записалась в StringList, после чего идет сохранение в файл всех настроек...

Видимо, путано написал... Но может кто выскажет мысли? ;)

← →
Пробегал... (2008-03-02 19:20) [1]

а еще такой вопрос попутно:

вообще нормальным считается, если при запуске программы с помощью TIniFile открывается файл настроек, а закрывается он только при завершении программы?

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

А сейчас вдруг задумался и понял - а какой смысл хранить эти промежуточные буферы? Ведь когда надо можно просто считывать из TIniFile, а когда надо - записывать... Ну просто файл будет всегда держаться открытым...
Странно даже... А может есть у этого подхода какие-то минусы?

И еще вот что интересно, когда в TIniFile делаешь Write чего-либо, он сразу это записыват на диск? Если допустим сделать Write и через пару секунд отключить питание компьютера - это значение нужное окажется в файле? Или TIniFile как-то кеширует информацию? Если да - то как принудительно заставить сбросить его текущее состояние в файл?

← →
Eraser © (2008-03-02 19:21) [2]

возможно TMemIniFile спсет ОРД? )

← →
Пробегал... (2008-03-02 19:34) [3]

ага, наверное.

То есть, получается что TIniFile при Write сразу пишет на диск? А TMemIniFile пишет на диск только при Update?

← →
Пробегал... (2008-03-02 20:31) [4]

а TIniFile потокобезопасный класс?

← →
Eraser © (2008-03-02 20:40) [5]

> [4] Пробегал... (02.03.08 20:31)

нет.

← →
Пробегал... (2008-03-02 20:53) [6]

ну из разных потоков то надеюсь можно функции дергать?

В смысле, что из разных потоков, но в одно и тоже время только один поток

← →
Loginov Dmitry © (2008-03-02 21:21) [7]

> В смысле, что из разных потоков, но в одно и тоже время
> только один поток

Если соответствующую синхронизацию сделаешь, то будет безопасным. Если без синхронизации, то - создавай несколько TIniFile (при одновременной записи в ini-файл винда должна сама все синхронизировать)

← →
jack128_ (2008-03-03 09:06) [8]

> вообще нормальным считается, если при запуске программы
> с помощью TIniFile открывается файл настроек

О ты откуда знаешь, когда открывается и когда закрывается файл?? Создание объекта <> открытие файла.

> То есть, получается что TIniFile при Write сразу пишет на
> диск?
Это решает винда.

← →
Kolan © (2008-03-03 09:27) [9]

> Кто-нибудь знает, что будет быстрее работать  выборка/запись
> параметра в TIniFile или в TStringList.Values ? И сильно
> ли будет различаться скорость?

Возьми и мпроверь, делов на 5 минут&#133

← →
Паша 1 (2008-03-03 11:20) [10]

> при одновременной записи в ini-файл винда должна сама все
> синхронизировать

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

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

← →
DVM © (2008-03-03 17:20) [11]

> при одновременной записи в ini-файл винда должна сама все
> синхронизировать

С какой это стати?

← →
Anatoly Podgoretsky © (2008-03-03 19:26) [12]

> Паша 1 (03.03.2008 11:20:10) [10]

А какая разница, блокируешь ты или нет, да через миллисекунду данные будут поменены, хоть блокируй, хоть нет, результат одинаков - первый обижаетсяю

← →
Loginov Dmitry © (2008-03-03 22:13) [13]

> С какой это стати?

Проверил :(
Действительно, никакой синхронизации. И еще так в справке обрадовали: This function is provided for compatibility with 16-bit Windows-based applications. WIn32-based applications should store initialization information in the registry. Мол, ну не было в те времена средств синхронизации, поэтому - никаких вопросов к винде! Что интересно, каждый раз, когда происходит ошибка Unable to write to "..." в ini-файл добавляется байт #0A. К чему бы это? ))

Хорошо хоть в реестре есть синхронизация (1000 потоков с "одновременной" записью ни разу не глюкнули ;)

> с удовольствием напоролся на такие грабли при работе в сетке,
> удивительная каша выходит, если с разных станций писать

Вот звери! В один файл, да еще и с разных станций... Тут и стандартные средства windows по блокировке файла (вроде как) не действуют, поэтому каша очень возможна.

> если кто хочет залезть одновременно тудой же, то ждет разблокирования
> файла в цикле

А как ты циклом добъешься надежной блокировки?

← →
Loginov Dmitry © (2008-03-03 22:31) [14]

Ну хоть чтение параметров из ини-файла и деструктор у TIniFile выполнены совершенно "потокобезопасно"! ;)

← →
Loginov Dmitry © (2008-03-14 23:46) [15]

Кстати, насчет [7] (то, что "винда должна сама все синхронизировать") я не совсем ошибался. Почему-то на работе винда делает синхранизацию обращений к ini-файлам (одновременно 100 потоков в него пишут/читают, и ни одной ошибки при этом не возникает). Дома тот же самый тест постоянно выдает ошибку записи в ini-файл (Unable to write to file). В чем отличие - не понимаю. Винда и здесь и там - WinXP SP2 (на работе - с лицензией). Проц дома 2-ядерный, на работе 1-ядерный. Но, как я понял, от числа ядер это не зависит, т.к. при отключении второго ядра ошибки лезут точно также. Хочется все-таки установить, от чего зависит наличие или отсутствие синхронизации (может от наличия лизенции ;). Если кому-то уже известен ответ, по просьба здесь его привести.

В архиве (10 кбайт) лежат исходники программы для тестирования. В программе одна кнопка, при нажатии на которую создаются 100 потоков. Они выполняют запись и чтение из ini-файла. Ошибки пишутся в файл "testlog.log".
http://matrix.kladovka.net.ru/inifiletest.zip

Сообщите, пишутся ли в лог ошибки или нет. Чтобы разобраться, наверно, нужно привести параметры компьютера (должна же быть какая-то зависимость! и она обязательно найдется).

Вот что у меня:
Рабочий:
WinXP SP2 + лицензия
Athlon 2400+ (1 ядро)
512 Мбайт оперативы
Ошибок при работе с ini-файлами нет

Домашний 1:
WinXP SP2
Athlon 4600+ (2 ядра)
2Гб ОЗУ
Ошибки постоянно появляются

Домашний 2:
WinXP SP2
Celeron 1300 (1 ядро :)
512Мб ОЗУ
Ошибки постоянно появляются

Уж не знаю, какие еще параметры нужны...

← →
NailMan © (2008-03-14 23:54) [16]

запустил
везде пишет что-то вроде такого
14.03.2008 23:52:49.796 [ошибка] <ID потока: 1128> Запись и чтение прошли успешно

ну и что поток стартовал

проц athlon x2 5200+ 4Gb винда xp2 rus sp2 ператко.

---
P.L.U.R. and WBR, NailMan aka 2:5020/3337.13

← →
Loginov Dmitry © (2008-03-14 23:59) [17]

Значит тебе повезло, и винда синхронизирует работу с ini-файлами. А ошибки такие должны быть:
14.03.2008 23:58:33.359 [ошибка] <ID потока: 7628> Unable to write to C:\Delphi\Projects\Test\IniFileTest\testini.ini

← →
Loginov Dmitry © (2008-03-15 00:00) [18]

Совершенно не понимаю, от чего это зависеть может...

← →
Пробегал2... (2008-03-15 00:41) [19]

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

← →
Loginov Dmitry © (2008-03-15 07:30) [20]

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

Если бы все было так просто, по пост [15] не возник!

Думаю, следует указывать дополнительный параметр - номер версии Windows (можно к примеру запустить mspaint и вывести окно "О программе..."). Если в MS просто добавили синхронизацию, то так мы узнаем, с какой версии она работает. У меня на обоих домашних компьютером версия винды:
Версия 5.1 (сборка 2600.xpsp_sp2_rtm.040803-2158 : Service Pack 2)

← →
NailMan © (2008-03-15 09:11) [21]

Версия 5.1 (сборка 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2) из пэинта

---
P.L.U.R. and WBR, NailMan aka 2:5020/3337.13

← →
Пробегал2... (2008-03-15 13:23) [22]

Loginov Dmitry © (15.03.08 7:30) [20]
Если бы все было так просто, по пост [15] не возник!

а что он опровергает? На том компьютере где с 10-ю потоками летят ошибки - оставь 1 поток. Если ошибки исчезнут - доказательство.

> Loginov Dmitry © (14.03.08 23:46) [15]

Стоит ли возиться изучением того на какой версии вин эта эфемерная синхронизация будет работать, если толку от этого все равно не будет практического. Должно работать везде. А программа которая работает на одной версии вин и не работает на другой, которая отличает единичкой в билде вряд ли кому нужна.

> Loginov Dmitry (15.03.2008 7:30:20) [20]

Ой какая старая.

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

А польза такова: если юзеры вдруг начнут наезжать, что система вследствие работы с ini-файлами "глючит", то можно достойно ответить, мол мы тут не причем, у тебя винда глюченная, обнови ее! ;)

На работе версия винды точно такая же, что и дома:
Версия 5.1 (сборка 2600.xpsp_sp2_rtm.040803-2158 : Service Pack 2)

Похоже не в версии дело.
Кто-нибудь еще запускал тест? Каковы результаты?

← →
Паша 1 (2008-03-17 11:06) [27]

> Anatoly Podgoretsky © (03.03.08 19:26) [12]
> А какая разница, блокируешь ты или нет

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

← →
Пробегал2... (2008-03-17 13:18) [28]

Loginov Dmitry © (17.03.08 9:05) [26]
На работе версия винды точно такая же, что и дома:
Версия 5.1 (сборка 2600.xpsp_sp2_rtm.040803-2158 : Service Pack 2)

Похоже не в версии дело.

а ты таки почитай мои посты: [22], [19]

> а ты таки почитай мои посты: [22], [19]

Я эти посты читал. С одним потоком ошибки исчезают.

← →
Пробегал2... (2008-03-17 14:21) [30]

Loginov Dmitry © (17.03.08 13:34) [29]

тогда скорее всего это не от версии винды зависит, а от установленных обновлений. Собственно, версий у WinXP не так и много, а релизных может и вовсе одна, как раз эта сборка 2600. Которая может быть меняется только при установках SP

TIniFiles vs TStringList Найти похожие ветки