Состязание компиляторов: Delphi 10.4.2 против Delphi 10.3.3 под допингом

    Поддавшись всеобщему вау-эффекту от новости про улучшение производительности компилятора Delphi 10.4.2 я сделал свои тесты, и тоже сказал "WOW!". Но один из комментариев к статье меня немного отрезвил: "Я так понимаю, те, кто использовал IDE Fix Pack (большинство?), разницы в скорости вообще не ощутят? Да уж, достижение века!". Как я сам не подумал добавить в сравнение Delphi 10.3.3 с установленным IDE Fix Pack? Без этого варианта тесты действительно не полные.

Улучшение производительности компилятора Delphi 10.4.2

    Одним из основных улучшений RAD Studio 10.4.2 Sydney является значительное увеличение скорости работы компилятора Delphi. Согласно официальному анонсу, разработчики реализовали более 35 различных оптимизаций компилятора. На вебинаре "What's Coming in Delphi, C++Builder and RAD Studio 10.4.2 Sydney" был заявлен рост скорости в 90 процентов.

На сколько же реально выросла скорость работы компилятора в Delphi 10.4.2?

Кто такой TBufferedFileStream?

    Недавно в модуле System.Classes под описанием класса TFileStream я случайно заметил наследуемый от него класс TBufferedFileStream. Судя по документации, TBufferedFileStream добавляет поддержку буферизации в TFileStream, тем самым оптимизируя небольшие последовательные операции чтения/записи файла. Давайте разберемся, что это за зверь, когда и откуда он появился, и, что он дает?

О пользе свойства Capacity

    Многие классы, у которых есть список элементов, имеют свойство "Capacity" или его аналог. Можно всю жизнь программировать и не догадываться о его существовании. Но оно есть. Так зачем оно нужно и как его использовать?

Правильный обход матрицы

    В статье Романа Кунина "Оптимизация кода: память" рассмотрены две функции на C++, которые суммируют элементы матрицы. Они практически одинаковы, только первая функция обходит элементы матрицы по строкам, а вторая по столбцам. Проведем подобный тест на Delphi 7 и Delphi 10.3.2.
    В отличии от оригинального теста, в котором суммируют элементы матрицы я предлагаю еще измерить скорость заполнения матрицы.

Запись в MS Excel. Кто быстрее?

    В марте этого года я протестировал скорость чтение информации из файла MS Excel библиотеками работающие с файлом MS Excel "напрямую" (Чтение из MS Excel. Кто быстрее?). Сегодня давайте взглянем, как эти библиотеки справляются с записью файла.
    Мой тест создает новый XLSX-файл с одним листом, на который записывает 10000 строк по 100 столбцов.

const
  ciRowCount = 10000;
  ciColCount = 100;

Каждая библиотека формирует файл 10 раз и результатом теста является среднее время. В качестве компилятора использована RadStudio v10.3.2. А результаты подтверждены на другом компьютере с компиляцией в RadStudio v10.3.1.

Чтение из MS Excel. Кто быстрее?

    При написании "Заполнение страницы MS Excel одной командой" я вспомнил про библиотеки работающие с файлом MS Excel "напрямую". Посмотрим, насколько чтение информации из MS Excel "напрямую" быстрее, чем при использовании OLE.
    Создадим файл с 1 000 000 строк по 5 столбцов и прочитаем его различными способами.

Заполнение листа MS Excel одной командой

	"А чё, так можно было, что ли?!?"
	© Уральские пельмени

    Недавно, правя баги в чужом проекте, я в методе генерации отчета в шаблон MS Excel обнаружил то, о чем сам никогда не задумывался... Среди сотни строк присвоения значений ячейкам, я заметил, что одна таблица из сотни ячеек копируется на лист MS Excel одной строкой...
    Алгоритм очень прост: создаем динамический двумерный вариантный массив, заполняем его значениями и присваиваем диапазону ячеек:

Delphi 2010: TValue - "тормоз"!

Перевод. Оригинал "TValue is very slow" (© TURBU Tech) дополнен моими тестами и комментариями.

   Справочная система Delphi 2010 описывает тип TValue, используемый модулем RTTI для хранения значений произвольных типов, как "облегченная версия типа Variant". Увидев это, я задался вопросом, насколько он легковеснее? Как быстро работает TValue?
   К счастью, среди известных мне новых возможностей Delphi 2010 – модуль диагностики (Diagnostics), который предоставляет нам объект TStopwatch – простой таймер позволяющий засечь время выполнения операций и тем самым облегчить написание простого теста скорости.
   Я ожидал, что скорость работы TValue будет сравнима со скоростью Variant, или возможно немного больше. Для проверки, я написал следующую программку:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils, rtti, diagnostics;

const
  HUNDRED_MILLION = 100000000;

procedure tryTValue;
var
  i: integer;
  j: TValue;
  value: integer;
begin
  for I := 1 to HUNDRED_MILLION do
    begin
      j := i;
      value := j.AsInteger;
    end;
end;

procedure tryVariants;
var
  i: integer;
  j: variant;
  value: integer;
begin
  for I := 1 to HUNDRED_MILLION do
    begin
      j := i;
      value := j;
    end;
end;

var
  stopwatch: TStopWatch;
begin
  try
    stopwatch := TStopWatch.StartNew;
    tryVariants;
    stopwatch.Stop;
    writeln('Variants: ', stopwatch.ElapsedMilliseconds);

    stopwatch := TStopWatch.StartNew;
    tryTValue;
    stopwatch.Stop;
    writeln('TValues: ', stopwatch.ElapsedMilliseconds);
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  readln;
end.

   Конечно, этот тест - не исчерпывающая проверка возможностей TValue, но результаты поучительны. Когда я запустил его на своем рабочем компьютере (высокопроизводительный ноутбук Alienware), тест Variant выполнился почти мгновенно, а тест TValue выполнялся так долго, что я решил, что он завис и остановил его.
   Затем я запустил тест снова и получил следующие результаты (в миллисекундах):

Variants: 717
TValues: 31131

   По крайней мере, для этой конкретной операции, TValue в 43.52167832167832 раза медленнее, чем Variant!

От меня.

   Вообще то 31131 поделить на 717 будет равно 43.41841004 ;)
   Что бы проверить результат, я запустил несколько тестов на своей домашней "dev machine".

Тест #1. Запустил исходный тест и получил такую же разницу скорости - в 43.17657992 раза:

Variants: 538
TValues: 23229.

Тест #2. Переставил местами вызов tryTValue и tryVariants и снова получил 43.376404494:

TValues: 23163
Variants: 534.

Тест #3. Закомментировав обратное присвоение TValue и Variant целой переменной ("value := j.AsInteger" и "value := j") я получил для TValue более "веселый" результат:

Variants: 535
TValues: 5168

Присвоение целого значения TValue медленнее присвоения целого значения Variant всего в 9.65981308 раза. А значит основное падение скорости вызвано AsInteger.

Тест #4. В процедуре tryTValue я заменил "value := j.AsInteger" на "value := j.AsOrdinal"

Variants: 536
TValues: 5862

В результате общее падение скорости всего в 10.93656716 раза!

Тест #5. AsOrdinal возвращает значение типа Int64, поэтому в процедуре tryTValue я заменил "value := j.AsInteger" на "value := j.AsInt64" и получил падение скорости в 54,25981308 раза!!!

Variants: 535
TValues: 29029

Вывод: "value := j.AsOrdinal" у TValue работает почти так же быстро, как и "value := j" для Variant. А методы AsInteger и AsInt64 – лучше не использовать. Но все равно, главный вывод: TValue – "тормоз"!

   Напоследок, я проверил с помощью функции SizeOf число байт, которые занимали переменные: переменная типа Variant занимала – 24 байта, а TValue – всего 16. Может в этом проявляется "облегченность" типа TValue? Тогда, храните числа в integer – они будут занимать 4 байта ;)