О уродах и козлопитонах.

[metaclass]

Импортирую данные из старой бухгалтерской проги в свою.
Прога использует файловые базы на кларионе.
Так вот оный долбаный кларион реализует чтение файла так:
вывод из filemon:

APP.EXE:4012 READ TABLEFILE.DAT SUCCESS Offset: 447430248 Length: 5
APP.EXE:4012 READ TABLEFILE.DAT SUCCESS Offset: 447430253 Length: 544
APP.EXE:4012 READ TABLEFILE.DAT SUCCESS Offset: 447430797 Length: 5
APP.EXE:4012 READ TABLEFILE.DAT SUCCESS Offset: 447430802 Length: 544

Никаких мыслей о том, что обмен надо вести блоками, кратными странице файловой системы,
в голове у разработчиков не возникло.

Comments

[(Anonymous)]

ОС сама всё заоптимизирует. Кэширование же никто в здравом уме не отключает.

[(Anonymous)]

Да и сериализация в MFC наверняка делает разбор файла аналогично, но никто на неё не жалуется.

[metaclass.livejournal.com]

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

[metaclass.livejournal.com]

И тем не менее, СУБД имеют собственный файловый кэш и выполняют обмен с диском целыми страницами. Я как-то эти же самые кларионовские файлы читал в двух разных вариантах - так же кларион - по записям, и со страничным обменом - вычитывал целиком блок в память - во втором варианте производительность была выше на 30% где-то.

[medvedd.livejournal.com]

Имела ли смысл данная оптимизация в те времена, когда данный Кларион был написан? :)