Денис,

> высказывание типа: "вот это тормозит в 2 раза" очень некорректно, и очень далеко от истины, чтобы языку присваивать клеймо — "в 2 раза медленней!".

Я нигде не говорил, что язык в 2 раза медленней (такое высказывание с моей точки зрения вообще не имеет смысла). Я измерял конкретные test cases, которые, да, примерно в 2 раза медленнее.

> (Особенно было смешно про видео-плейер.)

Это была иллюстрация того, что может означать замедление в 2 раза в ответ на совершенно конкретный вопрос Тимофея: "Два раза это так плохо?". Это не означает, что использование C# вообще или generics в частности означает обязательное замедление в 2 раза.

> На моей машине Cel2500 такие показатели:
> C++ — 46 сек.
> C# — 18 сек.
> Тогда я могу сделать однозначный вывод по поводу производительности?

Да, конечно, можно сделать однозначный вывод о том, что данный фрагмент кода на VC++ выполняется в два с половиной раза медленнее, чем на C#. Более того, можно даже объяснить, почему это происходит, и что по этому поводу можно сделать. На мой взгляд, любые шаги на пути к пониманию подобных моментов полезны.

> Линейной и тем-более константной зависимости тут нет, и быть не может

Речь идет о зависимости падения производительности от повышения уровня абстракции, т.е. в данном случае количества "слоев" использования generics и разнообразных оберток вокруг простых типов. Эта зависимость вполне может быть как константной, так и линейной, равно как и фактически любой другой. Правда, подозреваю, что дальше линейной на практике дело не пойдет.

> Ясно одно, что в достаточно крупных приложениях очень часто используется дин. память, поэтому в словах Влада истина в том, что зачастую при миграции более менее крупного проекта с C++ на C# заметно повышение производительности на глаз.

Еще раз: я не делаю никаких общих выводов. Речь о стоимости использования конкретных техник. А именно, применения generic программирования к абстракциям уровня value-классов. Производительность подсистемы управления памятью меня в данных test cases вообще не интересует, т.к. код был специально написан таким образом, чтобы по возможности исключить выделение/освобождение памяти в замеряемых фрагментах.