Здравствуйте, Serginio1, Вы писали:

S>>>Файловые базы всегда были быстрее ибо все происходит в одном процессе.
НС>>Или не потому.
S>А за счет чего?

1. Запись на файл быстрее за счёт асинхронности.
Записывая данные в файл, твоя программа обычно не ожидает завершения фактической записи на диск.
Попробуй на каждый чих делать что-то типа Flush() и прочувствуй разницу.

2. Чтение из файла быстрее за счёт кеширования.
При повторном чтении того же файла ты будешь с большой вероятностью читать данные не с диска, а из RAM.

Но GUI приложению доступны те же технологии, просто ими надо озаботиться самостоятельно.

Я когда-то еще в конце 90-х баловался с асинронщиной и кешированием — только это и позволяло вменяемо работать в случае, когда сервер приложений на другой машине, т.е. в трехзвенке.
При том что основной парк тогдашних клиентских машин — от пней-2 233-333 до селерона-3 700 (уже в 2000-м).


S>Интерпретатор выигрывает!

Интерпретатор — он для юзверского кода.
Но на системном уровне можно было сделать и асинхронщину, и локальное кеширование с синхронизацией.
В т.ч. локальное кеширование в локальной БД (я кешировал в локальной БД MS Access).

Например, при вводе справочных данных клиент не ожидал ответного суррогатного auto-number ключа, т.к. клиент еще в начале работы резервирует себе уникальный список ключей, т.е. всегда при вставке знает суррогатный ключ справочной записи, поэтому ему не требуется синхронно ожидать ответ для продолжения работы.