кстати, есть очевидное место, где имеется реюз переменных для интерфейсов — это циклы
type
TTest = class(TInterfacedObject)
public
destructor Destroy; override;
end;
function CreateTest: IUnknown;
begin
Result := TTest.Create;
end;
procedure TForm3.FormCreate(Sender: TObject);
var
I: Integer;
begin
for I := 0 to 3 do CreateTest;
ShowMessage('AfterLoop');
end; // последний инстанс TTest - будет тут уничтожен.
{ TTest }
destructor TTest.Destroy;
begin
ShowMessage('TTest.Destroy');
inherited;
end;
ух… Говорил он это в своем блоге, как раз когда автодестроеерер предлагал(c другой реализацией, конечно) Ссылку конкретную не дам, это наверно лет 5 назад было, а может и больше. Когда только delphi2009 с дженериками вышла…
>> Я выкинул счетчик ссылок, опираясь на то, что мы TMyRecord не будем никуда передавать
К сожалению дельфя может сама, неявно копировать рекорды. Можно попробовать реализовать что то типа плюсового auto_ptr'а конечно, но я бы не рисковал. Менеджер памяти в дельфе действительно хорош и дает не таких уж сильные накладные расходы.
Вспоминается история в eve online лет так 6 назад, там, если я правильно помню, шпион слил корпе строившийся титан, вот пострадавшие обратились в рельный суд, они де реальное время тратили, а тут вот такой гад все плоды их трудов в унитаз слил. Тогда суд их (как и разрабы игры) послал.
ЗЫ те кто читал недавный отчет о крупной битве в еве — поверте, 6 лет назад титан это было реально круто и слив одного — это драма на форумах на месяц минимум.
теоретически — может оптимизировать. А на практике проблема JIT компиляторов в трех буквах «JIT». Они работают во время работы программы, соответственно у них просто нет времени на оптимизации.
вместо тестирования работы компилятора — тестируем систему ввода вывода компа. При этом в дельфи — грузим файл в память целиком за одну операцию чтения, а в плюсах — построчно. Ну всякие мелочи, типа использования в дельфе хеш-таблицы, а в плюсах — деревьев, даже и говорить стыдно.
Провел эксперимент: написал 2 похожие по функционалу операции работы с шаблонными объектами, а именно запись в ассоциативный массив и чтение из ассоциативного массива.
Ну да, в таких тестах дельфя конечно выигрывает. Рецепт прост:
вместо тестирования работы компилятора — тестируем систему ввода вывода компа. При этом в дельфи — грузим файл в память целиком за одну операцию чтения, а в плюсах — построчно. Ну всякие мелочи, типа использования в дельфе хеш-таблицы, а в плюсах — деревьев, даже и говорить стыдно.
БРАВО!!! Эмбаркодеровцы, прошу обратить внимание на xpert13, он явно достойный евангелист Дельфи.
Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.
Оригинальная постановка. Ты понимаешь, что например скорость считывания с диска гигового файла практически не зависит от ЯП и компилятора?
Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.
А я и не говорил, что не зависит, более того она по любому зависит, по другому и быть не может.
Еще раз процитирую
Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
Два слова: «единичные случаи». Можете привести больше примеров доминирование одного языка программирования по скорости над другим, хотя бы десяток? А если я приведу диаметрально противоположные примеры для тех же языков, то что это значит?
Да любой код на плюсах с шаблонами _всегда_ быстрее по сравнению с кодом на дельфи с виртуальными методами/указателями на функцию. Как частный случай — это лямбды.
Смена языка однозначно значительно ускорит программу?
смотря как это язык выбирать.
Скорость работы программы не зависит от программиста?
Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.
А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
А это уже однозначно зависит от программиста и больше не от чего другого. У одних и с первого раза нормальный код не получается, а другие внеся десятки изменений умудряются получить чистый и читаемый код.
Угу, только проблема в том, что таких идеальных программистов нету в реальной жизни. А если вспомнить, что обычно чем быстрее алгоритм, тем он сложнее…
Я говорил о том, что для программиста, который винит медленную скорость работы программы язык программирования, смена этого языка не очень то и поможет, потому что в первую очередь нужно оптимизировать алгоритмы.
Вроде и на плюсах, и на джаве скрипте приводил примеры — и все равно не помогает. Да уж. Оптимизируют алгоритмы не потому что смена ЯП помогает или не помогает, а потому что сама по себе смена ЯП стоит времени и денег, больших чем оптимизация алго.
Вроде простая мысль же. Если на выходе компилятора быстрый код, значит вероятность что тебе придется этот код оптимизировать меньше. А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
Это да, но если код изначально плохо оптимизирован, то смена языка программирования не даст значительного прироста в скорости
смена языка программирования при плохом исходном коде даст ровно тоже ускорение, что и имена оного при хорошем коде. Если язык/компилятор дает хреновый маш. код для пузырьковой сортировки, то и для quicksort он выдаст хреновый маш. код.
Ну вот например, классический пример в холиварах C vs C++ ideone.com/E5JDWq.
ВНЕЗАПНО разница от смены языка программирования в три с гаком раза. Хотя конечно можно сказать, что «три раза» — это не значительная разница. Причем тут компилятор даже один и тот же, прирост обусловлен только языком.
Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
А теперь почему то начинаешь сравнивать свой код и код каких то программистов на C#.
Я вообще не знаю, как можно не понимать простой вещи. Если пишут ПО люди равной квалификации, то как раз наоборот, единственное от чего зависит скорость результирующего продукта — это язык/компилятор.
Скорость работы программы в большей мере зависит от программиста, а не от языка программирования. Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
да?? то есть если например написать браузер целиком на плюсах, а потом на руби при одинаковых временных рамках, то его скорость будет одинакова? то есть ты вот так утверждаешь??
Ну во первых не только паблишед свойства, но и ещё всё, что в DefineProperties определено. А во вторых а что, CopyComponentProp копирует не только паблишед свойства??
А зачем восстанавливать копировать свойства Result через CopyComponentProp?
вроде как TStream.WriteComponent/WriteComponent и так должны скопировать все свойства?
Примитивный пример:
гораздо веселее, когда результат вызова GetItem сохраняется в поле какого нить класса, о обращение к этому полю идет в другой момент, ну там например при клике по кнопке юзером. Или когда результат вызова GetItem замыкается linq-to-objects запросом или там лямбдой куда нить в TPL уходит. Вот тут начинается тут начинаются долгие ночи в обнимку с дебагером.
Может. Но Barry Kelly говорил, что такое маловероятно.
К сожалению дельфя может сама, неявно копировать рекорды. Можно попробовать реализовать что то типа плюсового auto_ptr'а конечно, но я бы не рисковал. Менеджер памяти в дельфе действительно хорош и дает не таких уж сильные накладные расходы.
а уж какие волшебные баги может вызвать код PInteger(Random())^ := Random();
ЗЫ те кто читал недавный отчет о крупной битве в еве — поверте, 6 лет назад титан это было реально круто и слив одного — это драма на форумах на месяц минимум.
Потому что в первом случае это автосвойство, инициализируемое в конструкторе один раз, а во втором — вычисляемое при каждом обращении свойство.
rsdn.ru/forum/dotnet/5401930.1
вместо тестирования работы компилятора — тестируем систему ввода вывода компа. При этом в дельфи — грузим файл в память целиком за одну операцию чтения, а в плюсах — построчно. Ну всякие мелочи, типа использования в дельфе хеш-таблицы, а в плюсах — деревьев, даже и говорить стыдно.
не по существу?? Ну тогда гудбай.
Ну да, в таких тестах дельфя конечно выигрывает. Рецепт прост:
вместо тестирования работы компилятора — тестируем систему ввода вывода компа. При этом в дельфи — грузим файл в память целиком за одну операцию чтения, а в плюсах — построчно. Ну всякие мелочи, типа использования в дельфе хеш-таблицы, а в плюсах — деревьев, даже и говорить стыдно.
БРАВО!!! Эмбаркодеровцы, прошу обратить внимание на xpert13, он явно достойный евангелист Дельфи.
Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.
Оригинальная постановка. Ты понимаешь, что например скорость считывания с диска гигового файла практически не зависит от ЯП и компилятора?
А я и не говорил, что не зависит, более того она по любому зависит, по другому и быть не может.
Еще раз процитирую
Да любой код на плюсах с шаблонами _всегда_ быстрее по сравнению с кодом на дельфи с виртуальными методами/указателями на функцию. Как частный случай — это лямбды.
Смена языка однозначно значительно ускорит программу?
смотря как это язык выбирать.
Скорость работы программы не зависит от программиста?
Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.
А это уже однозначно зависит от программиста и больше не от чего другого. У одних и с первого раза нормальный код не получается, а другие внеся десятки изменений умудряются получить чистый и читаемый код.
Угу, только проблема в том, что таких идеальных программистов нету в реальной жизни. А если вспомнить, что обычно чем быстрее алгоритм, тем он сложнее…
Вроде и на плюсах, и на джаве скрипте приводил примеры — и все равно не помогает. Да уж. Оптимизируют алгоритмы не потому что смена ЯП помогает или не помогает, а потому что сама по себе смена ЯП стоит времени и денег, больших чем оптимизация алго.
Вроде простая мысль же. Если на выходе компилятора быстрый код, значит вероятность что тебе придется этот код оптимизировать меньше. А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
смена языка программирования при плохом исходном коде даст ровно тоже ускорение, что и имена оного при хорошем коде. Если язык/компилятор дает хреновый маш. код для пузырьковой сортировки, то и для quicksort он выдаст хреновый маш. код.
Ну вот например, классический пример в холиварах C vs C++ ideone.com/E5JDWq.
ВНЕЗАПНО разница от смены языка программирования в три с гаком раза. Хотя конечно можно сказать, что «три раза» — это не значительная разница. Причем тут компилятор даже один и тот же, прирост обусловлен только языком.
Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
А теперь почему то начинаешь сравнивать свой код и код каких то программистов на C#.
Я вообще не знаю, как можно не понимать простой вещи. Если пишут ПО люди равной квалификации, то как раз наоборот, единственное от чего зависит скорость результирующего продукта — это язык/компилятор.
Согласен. Правда шибко большим умом я не отличаюсь. поэтому взял дельфийский код из эпичного треда forums.embarcadero.com/thread.jspa?threadID=74930 и перевел на java script gist.github.com/jack128/7983236
в результате на моей машине delphi xe4 (32bit релиз) 1,8sec
node v0.10.23 — 1,069sec
да?? то есть если например написать браузер целиком на плюсах, а потом на руби при одинаковых временных рамках, то его скорость будет одинакова? то есть ты вот так утверждаешь??
вроде как TStream.WriteComponent/WriteComponent и так должны скопировать все свойства?
гораздо веселее, когда результат вызова GetItem сохраняется в поле какого нить класса, о обращение к этому полю идет в другой момент, ну там например при клике по кнопке юзером. Или когда результат вызова GetItem замыкается linq-to-objects запросом или там лямбдой куда нить в TPL уходит. Вот тут начинается тут начинаются долгие ночи в обнимку с дебагером.