Есть ли различие в производительности между inc (i) и мной: = я + 1 в Delphi?

14
задан Niklas Winde 1 October 2008 в 08:08
поделиться

6 ответов

Современные компиляторы оптимизируют код.
inc (i) и я: = i+1; в значительной степени то же.

Использование, какой бы ни Вы предпочитаете.

Редактирование: Поскольку Jim McKeeth исправил: с Проверкой переполнения существует различие. Inc не делает проверки диапазона.

7
ответ дан 1 December 2019 в 07:53
поделиться

Существует огромная разница, если Проверка переполнения включена. В основном Inc не делает , делают проверку переполнения . Сделайте, как был предложен, и используйте окно дизассемблирования для наблюдения различия, когда Вам включили те параметры компилятора (это отличается для каждого).

, Если те опции выключены, то нет никакого различия. Эмпирическое правило, используйте Inc, когда Вы не заботитесь об отказе проверки диапазона (так как Вы не получите исключение!).

17
ответ дан 1 December 2019 в 07:53
поделиться

Все это зависит от типа "i". В Delphi каждый обычно объявляет переменные цикла как "я: Целое число", но это мог также быть "я: PChar", который разрешает к PAnsiChar на всем ниже Delphi 2009 и FPC (я предполагаю здесь), и к PWideChar на Delphi 2009 и Delphi.NET (также предполагающий).

Начиная с Delphi 2009 может сделать математику указателя, Inc (i) может также быть сделан на введенных указателях (если они определяются с включенным POINTER_MATH).

, Например:

type
  PSomeRecord = ^RSomeRecord;
  RSomeRecord = record
    Value1: Integer;
    Value2: Double;
  end;

var
  i: PSomeRecord; 

procedure Test;
begin
  Inc(i); // This line increases i with SizeOf(RSomeRecord) bytes, thanks to POINTER_MATH !
end;

Как другой anwsers, уже сказанный: это relativly легкий видеть то, что компилятор сделал из Вашего кода путем открытия:

Представления> Окна отладки> Windows ЦП> Дизассемблирование

Примечание, что параметры компилятора как ОПТИМИЗАЦИЯ, OVERFLOW_CHECKS и RANGE_CHECKS могли бы влиять на конечный результат, таким образом, необходимо заботиться, чтобы иметь настройки согласно предпочтению.

А снабжают подсказкой на этом: В каждой единице, $INCLUDE файл, который регулирует параметры компилятора, этот путь, Вы не освободите настройки, когда Ваш .bdsproj или .dproj будут так или иначе повреждены. (Посмотрите на исходный код JCL для хорошего примера на этом)

6
ответ дан 1 December 2019 в 07:53
поделиться

Можно проверить его в окне CPU при отладке. Сгенерированные инструкции ЦП являются тем же для обоих случаев.

я соглашаюсь Inc(I); взгляды лучше, хотя это может быть субъективно.

Исправление: Я просто нашел это в документации для Inc:

"На некоторых платформах, Inc может генерировать оптимизированный код, особенно полезный в жестких циклах".

, Таким образом, вероятно, желательно придерживаться Inc.

3
ответ дан 1 December 2019 в 07:53
поделиться

Вы могли всегда писать обе части кода (в отдельных процедурах), помещать точку останова в код и сравнивать ассемблер в окне CPU.

В целом, я использовал бы inc (i) везде, где он, очевидно, используется только в качестве какого-то цикла/индекса, и + 1 везде, где этот 1 сделал бы код легче поддержать (т.е., он мог бы мыслимое изменение в другом целом числе в будущем), или просто более читаемый с точки зрения алгоритма/спецификации.

1
ответ дан 1 December 2019 в 07:53
поделиться

"На некоторых платформах Inc может генерировать оптимизированный код, особенно полезный в жестких циклах". Для оптимизированного компилятора, такого как Delphi это не заботится. Это о старых компиляторах (например, Turbo Pascal)

0
ответ дан 1 December 2019 в 07:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: