Когда Вы не могли бы хотеть использовать сборку "мусора"? [закрытый]

Я могу думать о некоторых:

Детерминированное освобождение/очистка

Системы реального времени

Не бросая половину памяти или процессорное время - в зависимости от алгоритма

Более быстрая память alloc/dealloc и специализированное выделение, освобождение и управление памятью. В основном при записи собственного материала памяти - обычно для производительности чувствительные приложения. Это может быть сделано, где поведение приложения довольно хорошо понято. Для GC общего назначения (как для Java и C#) это не возможно.

Править

Тем не менее GC, конечно, был хорош для большой части сообщества. Это позволяет нам фокусироваться больше на проблемной области, а не приемах программирования остроты или шаблонах. Я - все еще "неуправляемый" разработчик C++ все же. Хорошие методы и инструменты помогают в этом случае.

Выделения памяти? Нет, я думаю, что GC лучше в нем, чем я.

Но выделения дефицитного ресурса, как дескрипторы файлов, соединения с базой данных, и т.д.? Я пишу код для закрытия их, когда я сделан. GC не сделает этого для Вас.

Приложения реального времени, вероятно, трудно записать со сборщиком "мусора". Возможно, с возрастающим GC, который работает в другом потоке, но это - дополнительные издержки.

Один случай, о котором я могу думать, - когда Вы имеете дело с большими наборами данных, составляющими hundreads мегабайтов или больше. В зависимости от ситуации Вы могли бы хотеть освободить эту память, как только Вы сделаны с нею, так, чтобы другие приложения могли использовать ее.

Кроме того, когда контакт с некоторым неуправляемым кодом там мог бы быть ситуацией, где Вы могли бы хотеть препятствовать тому, чтобы GC собрал некоторые данные, потому что это все еще используется неуправляемой частью. Хотя я все еще должен думать о серьезном основании, почему просто хранение ссылки на него не могло бы быть достаточно хорошим.:P

Я делаю большую встроенную разработку, где вопрос, более вероятно, будет состоять в том, использовать ли malloc или статическое выделение, и сборка "мусора" не является опцией.

Я также пишу много основанных на ПК инструментов поддержки и буду счастливо использовать GC, где это доступно и достаточно быстро, и это означает, что я не должен использовать педанта:: станд.:: строка.

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

Таким образом, мой ответ - то, что существуют причины избежать GC, но причиной является почти всегда производительность, и затем лучше кодировать материал, которому нужен он на другом языке вместо того, чтобы пытаться обмануть GC.

Если я разрабатываю что-то в MSVC ++, я никогда не использую сборку "мусора". Частично, потому что это нестандартно, но также и потому что я вырос без GC в C++ и автоматически разрабатываю в безопасном восстановлении памяти. Сказав это, я думаю, что C++ является отвращением, которому не удается предложить прозрачность перевода и предсказуемость C или ограниченной по объему безопасности памяти (среди других вещей) более поздних языков OO.

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

Единственный способ сделать обработку на изображении на разумной скорости состоял в том, чтобы использовать неуправляемый код в моей ситуации. Это было при работе над маленьким персональным параллельным проектом в.NET C#, где я не хотел изучать стороннюю библиотеку из-за размера проекта и потому что я хотел изучить это лучше мне. Возможно, была существующая сторонняя библиотека (возможно, Paint.NET), который мог сделать это, но это все еще потребует неуправляемого кода.

Два слова: Укрепление Пространства

Я знаю крайний случай, но все еще применимый. Один из стандартов кодирования, которые относились к ядру марсоходов Марса на самом деле, запрещает динамическое выделение памяти. В то время как это - действительно экстремальное значение, оно иллюстрирует, "развертывают и забывают об этом без забот" идеал.

Короче говоря, имейте некоторый смысл относительно того, что Ваш код на самом деле делает к чьему-то компьютеру. Если Вы делаете, и Вы консервативны.. затем позвольте фее памяти заботиться об остальных. В то время как Вы разрабатываете на четырехъядерном, Ваш пользователь мог бы быть на чем-то значительно старше с намного меньшей памятью для экономии.

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

В теории, ничем. На практике, хотя, не используйте его, если это не может работать для Вашего приложения.

Различные алгоритмы GC могут или не могут быть эффективными для differnt типов приложений. Некоторые GCs лучше для длинных запущенных приложений, некоторые настраиваются для пропускной способности, некоторые настраиваются для сокращения задержки, и некоторые просто сосут в целом.

У меня было несколько экземпляров, где GC Java был меньше затем эффективен, и мне было жаль, что я не мог управлять своей собственной памятью. В основном я использовал ТОННУ памяти, которая стала мусором сразу же, и из-за способа, которым работал GC, часть его заканчивалась в 'штатном' поколении, когда это не должно было быть, и я не могу вынудить Java использовать набор копии для всей своей памяти.

Наличие 16 концертов поршня вместо 8, вероятно, решило бы проблему также. В целом, я просто должен был сделать некоторую дополнительную настройку для получения его работа, и так как я не могу выключить gc в Java, это была моя единственная опция.

Я подозреваю Java 7, новый GC решил бы мою проблему.

Существует два главных типа систем реального времени, твердых и мягких. Основное различие - то, что системы жесткого реального времени требуют, чтобы алгоритм всегда заканчивался в бюджете определенного времени, где, поскольку мягкая система хотела бы, чтобы он обычно произошел. Мягкие системы могут потенциально использовать хорошо разработанные сборщики "мусора", хотя нормальный не был бы приемлем. Однако, если бы алгоритм системы жесткого реального времени не завершался вовремя затем, то жизни могли бы быть в опасности. Вы найдете такие виды систем в ядерных реакторах, самолетах и шаттлах и даже затем только в программном обеспечении специалиста, из которого сделаны операционные системы и драйверы. Будьте достаточны, чтобы сказать, что это не Ваше общее задание программирования.

Люди, которые пишут эти системы, не склонны использовать языки программирования общего назначения. Ada была разработана в целях записи этих видов систем реального времени. Несмотря на то, чтобы быть специальным языком для таких систем в некоторых системах язык сокращен далее к подмножеству, известному как Spark. Spark является специальной безопасностью критическое подмножество языка Ada и одна из функций, которые это не позволяет, создание нового объекта. Новое ключевое слово для объектов полностью запрещается, чтобы его потенциал исчерпал память и его переменное время выполнения. Действительно весь доступ к памяти в Spark сделан с абсолютными ячейками памяти, или переменные стека и никакие новые выделения на "куче" сделан. Сборщик "мусора" не только полностью бесполезен, но и вреден для гарантируемого времени выполнения.

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

Примерно все эти ответы сводятся к производительности и управлению. Один угол, который я не видел в более ранних сообщениях, - то, что пропуск GC дает Вашему приложению более предсказуемое поведение кэша двумя способами.

1. В определенном кэше чувствительные приложения, имея язык автоматически повреждают Ваш кэш время от времени (хотя это зависит от реализации), может быть проблема.
2. Хотя GC является ортогональным к выделению, большинство реализаций дает Вам меньше контроля специфическими особенностями. Большому количеству высокопроизводительного кода настроили структуры данных для кэшей, и реализующий материал как забывающие о кэше алгоритмы требует более мелкомодульного управления расположением памяти. Хотя концептуально нет никакой причины, GC был бы несовместимым с ручным определением расположения памяти, я не могу думать о популярной реализации, которая позволяет Вам сделать так.

В видеоиграх Вы не хотите запускать сборщик "мусора", промежуточный игровой кадр.

Например, Большое и страшное перед Вами, и Вы - до 10 жизней. Вы решили работать к Квадратическому включению питания Повреждения. Как только Вы берете включение питания, Вы готовитесь для превращения к врагу для увольнения с самым сильным оружием.

Когда включение питания исчезло, это будет плохая идея запустить сборщик "мусора" просто, потому что игровой мир должен удалить данные для включения питания.

Видеоигры обычно управляют своими объектами путем выяснения того, что необходимо в определенной карте (это - то, почему она требует времени к картам распределения памяти при загрузке с большим количеством объектов). Некоторые игровые механизмы назвали бы сборщик "мусора" после определенных событий (после того, как, сохраняя, когда механизм обнаруживает, нет никакой угрозы в близости, и т.д.).

Кроме видеоигр, я не нахожу серьезных оснований выключить сборку "мусора".

Править: После чтения других комментариев я понял, что встроенные системы и Укрепление Пространства (комментарии счета и tinkertim, соответственно) являются также серьезными основаниями выключить сборщик "мусора"

Я не вполне понимаю вопроса. Так как Вы спрашиваете о языке, который использует GC, я предполагаю, что Вы просите примеры как

1. Сознательно держитесь за ссылку, даже когда я знаю, что это мертво, возможно, для многократного использования объекта удовлетворить будущий запрос выделения.
2. Отслеживайте некоторые объекты и закройте их явно, потому что они содержат ресурсы, которыми нельзя легко управлять со сборщиком "мусора" (открытые дескрипторы файлов, окна на экране, такой вещи).

Я никогда не находил причину сделать, № 1, но № 2 является тем, который иногда приходит. Много сборщиков "мусора" предлагают механизмы для завершения, которое является действием, которое Вы связываете с объектом и системными выполнениями, что действие перед объектом исправлено. Но часто система не обеспечивает гарантий о том, ли или если финализаторы, на самом деле выполненные, таким образом, завершение может иметь ограниченную утилиту.

Главное, которое я делаю на собравшем "мусор" языке, состоит в том, чтобы сохранить трудные часы на количестве выделений на единицу другой работы, которую я делаю. Выделение обычно является узким местом производительности, особенно в системах.NET или Java. Это - меньше проблемы на языках как ML, Haskell или LISP, которые обычно разрабатываются с идеей, что программа собирается выделить как сумасшедший.

Править: более длительный ответ на комментарий.

Не все понимают, что когда дело доходит до производительности, средство выделения и GC нужно рассмотреть как команду. В состоянии системы выделение сделано от непрерывного свободного пространства ('детский сад') и так же быстро как тест и инкремент. Но если выделенный объект не является невероятно недолгим, объект подвергается долгу по линии: это должно быть скопировано из детского сада, и если это живет некоторое время, это может быть скопировано через несколько generatations. Лучшие системы используют непрерывное свободное пространство для выделения и в какой-то момент переключаются от копирования, чтобы отметить/развернуть или отмечать/сканировать/уплотнять для более старых объектов. Таким образом, если Вы очень придирчивы, можно сойти с рук игнорирование выделений если

• Вы знаете, что имеете дело с современной системой, которая выделяет от непрерывного свободного пространства (детский сад).
• Объекты, которые Вы выделяете, являются очень недолгими (меньше чем один цикл выделения в детском саду).

Иначе выделенные объекты могут быть дешевыми первоначально, но они представляют работу, которая должна быть сделана позже. Даже если стоимость самого выделения является тестом и инкрементом, сокращение выделений является все еще лучшим способом улучшить производительность. Я настроил десятки программ ML с помощью современных средств выделения и коллекторов, и это все еще верно; даже с самой лучшей технологией, управление памятью является общим узким местом производительности.

И Вы были бы удивлены, сколько средств выделения не имеет дело хорошо даже с очень недолгими объектами. Я просто получил большое ускорение от Lua 5.1.4 (вероятно, самый быстрый из языка сценариев с GC поколений) путем замены последовательности 30 замен, каждая из которых выделила новую копию большого выражения с одновременной заменой 30 имен, которые выделили одну копию большого выражения вместо 30. Проблема производительности исчезла.