[опрос] Garbage Collector медленнее ручного управления памятью?

Сильно зависит от задачи. Перевес может быть в ту или иную сторону.

Например, язык Си крайне эффективен за счет простоты используемых конструкций. Если этих конструкций хватает, то все здорово. Если нет, то тут более высоко-уровенный язык с GC может выиграть.

Ограничимся управлением памятью, без нюансов языка.

В 146 % ровно.

Ага, вопрос сродни - насколько http серверы медленнее jsonrpc поверх tcp.
Что с чем сравнивать? В общем? Идиотизм:)
Аллокаторы разные, можно на стеке выделять, можно выделять заранее, при компиляции. И если грамотно комбинировать, то даже в теории gc не сможет сравниваться по скорости. Просто потому, что правильное планирование использование ресурсов делает gc не нужным, но требует планирования:)
С другой стороны, gc может быть как тупотупой, который начинает свою работу только после некоторого критического пожирания памяти или конца жизни некоторой почти глобальной области видимости. Так и очень умный, многопоточный, проверяющий актуальность всех ссылок в реальном времени. Второй вариант может уделать ручное управление c помощью free(), delete и тд.
В общем и целом зависит от реализации.

Например понятие eden позволяет вызывать new в куче со скоростью выделения в стеке. Вообщем-то перекладывается время работы на сборку. При том, что стоимость сборки мертвого обьекта стоит 0.

Управление памятью не просто нюанс, а жирная черта разделяющая одни языки от других. Есть и смешанные языки на подобии Obj-C и Ada, где ручное управление совмещается с автоматическим. В общем, по GC можно классифицировать языки.

Что касается процентов, то получится средняя температура по больнице. Оно надо?

Ясно, что иногда GC может быть эффективнее. В том числе, благодаря человеческому фактору. Тут спорить не о чем, хотя всегда найдутся программисты и близкие к ним по профессии люди, которые станут возражать. Особенно «близкие».

Программы создают люди, и это ключевой момент. Если бы писали роботы, то тогда, быть может, ручное управление всегда было бы эффективнее, чем GC. Но это не так.

В 100%. Хотя бы потому, что garbage collector это частный случай ручного управления памятью.

В скольких процентах задач...

О_о «Есть ли жизнь на Марсе?»

Статистику не назову - всякое бывало, но цифр не считал. Учти, еще что важна не только средняя скорость, а еще и latency. Тащемта, для риалтаймовых задач GC плохо годится.

в этом вопросе охрененно всё, от формулировки до уточнения

задай его лучше на форуме социологов

Тащемта, для риалтаймовых задач GC плохо годится

и в каких RT-задачах ты пробовал применять GC? и какой GC?

Лично мне не доводилось. Но у нас тут поиск на яве писали. Не то что бы оно совсем не годится, но пришлось много прыгать с бубном что бы оно во сколько там миллесекунд попадало.

Если счет идет на миллисекунды, то это ближе к верхней границе понятия RT. И если уже с этим проблемы, то какой тут нахрен может быть GC?

http://www.jwz.org/doc/gc.html - есть такое мнение.

Это всегда правда. Другое дело, что во многих случаях издержки из-за гравицапы мизерны.

В теории ручное управление памяти всегда может быть эффективнее автоматического: с одной стороны оно более гибкое, с другой — более дешёвое с точки зрения накладных расходов. На практике руками процесс управления обычно реализован довольно криво и далеко не всегда эффективнее чем в случае gc. Кроме того есть языки где gc не роскошь, а безусловная необходимость.

garbage collector это частный случай ручного управления памятью.

Чего только не услышишь на ЛОР.