Это пока единственный существенный недостаток алгоритма. У тебя все книги такие?

Да с этим надо что-то делать.

ADO тоже ведь с базой напрямую работает, надо будет подумать о переносе части работы в Native код.

p.s. Второго пункта в старом Библиотекаре нет, Fb2Library умет обновлять списки авторов/серий/книг во время импорта.

p.p.s Возможно скорость можно увеличить обрабатывая книги пачками (хотя бы по 10 штук) в одной транзакции, а не по одной как сейчас.

"Продвинутый" алгоритм сравнения дает не более 3% ошибок, а не 70% как ты пытаешься меня уверить. 70% означало бы, что из твоей тысячи были не правильно распознаны минимум 700 книг, в тестах я этого не наблюдаю и близко.

Будет.

1. Катастрофическая деградация производительности Firebird базы с увеличением объема
2. Обновление UI
3. Маршалинг из Manged в Unmanaged в FirebirdSql драйвере.

1. Размер странницы рекомендуется выбирать равным размеру кластера в файловой системе. Для NTFS стандартный размер кластера равен 4к (4096)
2. Флаг "Force Write" заставляет Firebird после каждого изменения в БД скидывать файловые буфера на диск. При этом повышается надёжность, но понижается производительность.

Доступно обновление, исправляющее данную проблему.

Gut, значит проблема в другом.

Диск на котором расположен каталог для временных файлов, часом не FAT32?

Не воспроизводится. Проблемы возможны, т. к. в этот модуль вносились изменения, но у меня всё запускается. Посмотрим, может у кого ещё такая проблема возникнет...