7 июн. 2010 г.

Тестирование подсистемы отчетов

При тестировании изменений в подсистеме отчетов мы постарались исключить фактор пропускной способности сети и производительности дисковой подсистемы. Использовался встроенный сервер Firebird 2.5. Данные генерировались с помощью хранимых процедур. Пример такой процедуры можно видеть ниже:
CREATE PROCEDURE tst_p_gen_str_data (i INTEGER)
  RETURNS (id INTEGER,
    s1 VARCHAR(60),
    s2 VARCHAR(60),
    s3 VARCHAR(60),
    s4 VARCHAR(60))
AS
BEGIN
  s1 = 'ABC dfg';
  s2 = '123 567 9874 10';
  s3 = 'qwertyuiop asdfghjl; xzcvnbvmn,m.';
  s4 = '';
  WHILE (i > 0) DO
  BEGIN
    id = :i;
    i = :i - 1;
  END
END
Тестировались следующие отчеты:
  1. Отчет по одному набору данных со строковыми полями.
  2. Отчет по одному набору данных с целочисленными полями.
  3. Отчет по двум наборам данных, связанных связью мастер-дитэйл. Наборы данных со строковыми полями.
Замеры выполнялись на втором построении отчета. Учитывалось время построения отчета и информация об использовании оперативной памяти, полученная с помощью программы Process Explorer.

Таблица с результатами находится здесь.

Вывод:
  • для отчетов мастер-дитэйл на двух датасетах разница незначительна — увеличение потребления памяти на 2% и ускорение на 6%.
  • для отчетов, основанных на одном наборе данных, достигается существенное ускорение в 35% при умеренном росте потребления памяти — от 9 до 16%.
Стоит заметить, что Fast Report 4 позволяет строить отчеты с группировкой (фактически, мастер-дитэйл)  с использованием одного набора данных.

1 комментарий:

Александр комментирует...

Ускорение MD зависит от того, какой тип датасетов используется. В тесте оба были TIBQuery, данный вариант самый медленный. Если для примера взять сводные ведомости из настройки ЗПиК, то там они построены на TClientDataSet-ах. Там у меня прирост по скорости достигал до 50% при таком же потреблении памяти. Если же один TIBQuery а второй TClientDataSet - то ускорение в пределах 10-12% при увеличении памяти 6-10%.

Отправить комментарий