Max Rezanov, Южно-Российский кадастровый центр "Земля"
15.06.2001: У меня появился новая версия OLE DB provider-а от 14 мая 2001 на результаты стоит посмотреть. Также выложены исходники программ которые собственно говоря все это и делали.
При рассмотрении участвовали:
BDE v 5.1 (входить в состав дельфи 5)
IBX v 4.42 (входить в состав дельфи 5)
FIBC v 4 (Copyright (c) 04.2000 by Serge Buzadzhy)
OLE DB provider от Lipetsk Center of Legal Informatization.
Общее состояние среды обитания: Windows 2000 prof rus, IB v 6.0.1 от борланда, на момент запуска тестового приложения ОЗУ - 71 МБ свободно из 128. Дельфи v 5.0 установлен ServicePack 1 и INTERBASE EXPRESS UPDATE KIT 42.
В чем состоял эксперимент: открытие базы данных, открытие выборки вида select * from table, полный фетч до конца набора данных. В таблице ~60 000 записей. Структура таблицы следующая:
CREATE TABLE table (
ID_ACT CHAR(10) NOT NULL,
ID_ADMUSERS CHAR(10) NOT NULL,
ID_RID CHAR(10) NOT NULL,
ID_ADMACTIONS CHAR(10) NOT NULL,
MASTER_TAG_ACT VARCHAR(10),
ID_MASTER_ACT CHAR(10) NOT NULL,
KOGDA_ACT DATE default 'NOW' NOT NULL,
DATE_ACT DATE,
RELSUB_ACT VARCHAR(100),
REM_ACT VARCHAR(255));
Время открытия пока рассматривать не будем.
Время
Общая картина представлена ниже
Очень интересно поведение OLE DB провайдера, если на начальном этапе он безусловно отстает, то в районе 18000 он догоняет IBX, а на 36200 обходит FIBC. Естественно после широкой рекламы в сети компонентов прямого доступа я был поражен тем, что BDE имеет самую быструю скорость фетча. Посмотрим на следующий параметр:
Память Delphi
Память инспектировалась посредством вызова процедуры дельфи AllocMemSize В принципе ничего нового не заметно: BDE & OLEDB не используют для своих наследников от TDataSet кеширования в среде дельфи, IBX & FIBC являсь натив компоенентами весь курсор держат в памяти непосредственно подконтрольной дельфи. Для полноты картины посмотрим на:
Память процесса.
Для анализа памяти процесса использовалось значение WorkingSetSize из структуры PROCESS_MEMORY_COUNTERS. Весьма интересная ситуация в районе 34 000 BDE сравнивается с компонентами прямого доступа и по использованию памяти ведет себя лучше на больших обьемах. Но самое веселое то, что OLEDB единственный компонент доступа давший возможность открыть так называемый серверный курсор без выжирания памяти приложения.
Теперь немного о том, для чего это делалось. Я считаю что для кеширования данных на клиенте есть достаточно удобное средство TClientDataSet. Обладающее достаточной функциональностью для отображения/редактирования и пр. махинаций с данными. Кроме того по последним новостям не требуещего лицензии в так называемом локальном варианте. Для того чтобы удобно получить данные в ClientDataSet желателен наследник от TDataSet потому, что именно в нем реализуется интерфейс IProviderSupport. Написание компонента наследованного от IBSQL и реализующего IProviderSupport не рассматривалось Ж:) по причине лени.
Выводов не будеть Ж:))
Результаты теста с новым провайдером OLEDB
По моему есть на что посмотреть: на фетче 60000 записи отрыв от DBE ,бывшего безусловным лидером, составляет почти секунду Ж:).
Все тесты выполняются программой GetInfo.exe для улучшения результатов лучше всего делать 2 прохода, чтобы позаполнять всякие системные и прочие кеши и попробовать получить "чистый" фетч. В результате работы программы получаеться 1-4 файла с расширением csv. Для первых 5000 записей съем времени/памяти происходить на каждые 10 записей, после 5000 для каждой 5000-ой. Для просмотра их удобно воспользоваться программой ShowInfo.exe. (Графики масштабируються Ж:) интересно посмотреть на самое начало фетча). Скомпилированные версии можно взять здесь
Если вы хотите посмотреть на исходники, то их можно загрузить отсюда для компиляции необходима библиотека RX Lib (кроме указанных компонентов доступа).
Ну и на последок мои версии данных в формате csv.