Не хочется кормить тролля, но один раз отвечу.Данный пример ничего полезного не делает и clang 3.9.1 компилирует его в функцию из одной инструкции ret: https://godbolt.org/g/aKZsWT Я думаю можно с уверенностью сказать, что нет ничего быстрее, чем пустая функция.
Но это всё благодаря оптимизации, когда мы видим, что память выделилась и тут же освободилась мы можем заменить аллокацию в хипе на аллокацию в стеке. GCC такую оптимизацию не делает. Я не знаю, про какую реализацию .NET ты говоришь, но приведенный код тоже может быть соптимизирован в ничто.
Хочу обратить внимание, что данный код на C++ пессимизирован и правильнее было бы создавать объект в стеке, просто: Node v; Тогда оба компилятора и clang и GCC компилируют код в пусто.
С бенчмарками есть одна проблема. Существует множество различных программ, в бенчмарке автор выбирает одну из них и сравнивает на ней. Вопрос, почему мы считаем этот один пример вообще репрезентативным?
Я хочу обратить внимание вот на какой факт. Все современные аллокаторы памяти работают для маленьких объектов (до ~1kb, а это 99.9% всех объектов) за O(1). Все современные GC так или иначе обходят весь хип, это может по разному называется, но это происходит. Они стараются делать это как можно реже (применяют гипотезу поколений, используют счетчики ссылок, чтобы не обходить, когда не возникают циклы -- разные делают разному), но это всё равно проиходит. То есть мы сравниваем O(1) и O(размера хипа).
Есть ещё один момент компирующие сборщики мусора копируют объекты. Как правило увеличение размера объектов приводит к тому, что GC случаются чаще и копировать памяти нужно больше. Т.е. GC чувствителен к размеру наших объектов. Обычные аллокаторы памяти на 64-битных системах к этому не чувствительны.
Таким образом по мере роста размера хипа и увеличения размера объектов GC будет работать всё хуже и хуже по сравнению с обычным аллокатором памяти. Конечно обычные бенчмарки обычно проводятся в условиях почти идеальных для GC (маленькие объекты, маленький хип).
Ещё один способ наврать в бенчмарках это заточиться на гипотезу поколений и сделать так, чтобы все объекты умирали не выходя из Gen0, собственно, что ты сделал в своем примере. Но ответ на это очень простой -- если объект коротко живущий его надо создавать в стеке. И если мы для коротко живущих объектов будем использовать стек, то на долго живщих обычный аллокатор, скажем jemalloc или tcmalloc, порвет на тряпки дотнетовский Gen2 GC.
