Что быстрее работает INI, XML, JSON
Суть  в какой формат будут сохраняться или читаться из него данные, например, не большой таблицы TListViev из 5 -10 колонок и около 10000 строк?
Если кто-нибудь тестил такие форматы на скорость - отзовитесь.

1. Для таких объемов существуют СУБД ИМХО
2. Писать в отображаемые списки тысячи строк - маразм. Не ИМХО

Txt

С фиксированной шириной колонок для скорости произвольного доступа, если оно надо.

> 1. Для таких объемов существуют СУБД ИМХО
> 2. Писать в отображаемые списки тысячи строк - маразм. Не
> ИМХО


Это раньше лет 15 назад было маразм, а сегодня не маразм, современный i7 такую оперцию с SSD накомителя делает за несколько секунд.

> [4] superb0t ©   (23.01.19 04:40)

И чё, цель засрать всю производительность железа?

Возьми встраиваемую СУБД, как посоветовали. Попробуй SQLite, например.

Интересно, а есть какие-нибудь библиотеки, которые работают с текстовими форматами типа этих INI, XML, JSON, CSV с использование многопотока или инструкций AVX

> И чё, цель засрать всю производительность железа?


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

В общем данные должны храниться в текстовом формате без вариантов.

*.xml + IXMLDomDocumentXX

и будет тебе и текст и sql-like возможности выборки данных и текстовый редактор и белка со свистком

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

> 2. Должна сохраниться возможность просмаьривать и редактировать список в текстовом редакторе.
можно использовать к примеру текст с разделителями (csv), редактировать и в блокноте можно, но в экселе/программе удобнее.

> например, не большой таблицы TListViev из 5 -10 колонок и около 10000 строк?
в ADODataset из csv пробовал, давно давно (очень старые машины по нынешним временам) 370 тыс (примерно насколько помню. количество... ну именно такой тестовый файл был, из реальных данных скопирован) колонок побольше (10-20), время считывания/открытия меньше секунды (то ли 500 мсек, то ли 700, опять таки не помню).

Чтение/запись всего массива целиком этих данных - примерно пофик в каком формате сделать. Какой короче - так и будет, очевидно, быстрее для операций "прочитать все" / "записать всё", если уж сравнивать.

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