Сообщение Re[3]: Важны ли мелочи в ЯП? от 04.01.2025 21:51
Изменено 04.01.2025 23:02 vdimas
Re[3]: Важны ли мелочи в ЯП?
Здравствуйте, Shmj, Вы писали:
S>Ну на счет квалификации — если нет встроенного механизма dispose — это не значит что теперь ресурсы станут бесконечными и вам не нужно будет об этом беспокоиться.
А это из опыта C#.
Отложенная финализация по-умолчанию — злейшее зло, как показала практика.
Этот механизм де-факто не работает, увы, хотя был разработан для сценариев, где невнимательный программист прошляпил своевременное освобождение ресурсов.
Например, лапша-программер забыл своевременно освободить какой-нить сокет-листенер — и затем прога не может повторно сесть на порт новым сокетом в течении десятков минут или даже нескольких часов, если прежний сокет уже убежал во второе поколение, а нагрузка на приложуху небольшая, т.е. второе поколения не трогается GC оч долго.
Поэтому, для чувствительных к освобождению ресурсов рулит или своевременная финализация, или никакая.
Плюс, для ресурсоёмких shared-объектов иерархия владения должна быть только одностороенней, тут хорошо работает ref-counting, не зря есть объекты InspectorReferenceData, которые обслуживают этот сценарий (в несколько строк ты можешь нарисовать свои хелперы для аналогичного).
Ну и, для отложенной финализации есть классы Finalizer и NativeFinalizer, которые, в отличие от C#, надо дёргать явно, т.е. в очередь финализации попадает не каждый объект.
Тут убивается сразу два зайца:
— явное задействование механизма подразумевает, что программер продумал схему управления ресурсами для целевых объектов, т.е. что отложенная финализация для целевых ресурсов допустима;
— в очередь финализации ставятся не все объекты подряд, а лишь единичные, что делает сборку мусора резко дешевле, чем в том же C#.
Плюс еще есть WeakReference в языке, а самое главное — миксины!
Миксины позволяют реализовать различные политики управления ресурсами лишь однажды (в неких своих миниатюрных хелперах, в т.ч. которые refcount), а затем использовать их в произвольных объектах.
В C#/Джаве такой трюк невозможен, опять же.
S>Ну на счет квалификации — если нет встроенного механизма dispose — это не значит что теперь ресурсы станут бесконечными и вам не нужно будет об этом беспокоиться.
А это из опыта C#.
Отложенная финализация по-умолчанию — злейшее зло, как показала практика.
Этот механизм де-факто не работает, увы, хотя был разработан для сценариев, где невнимательный программист прошляпил своевременное освобождение ресурсов.
Например, лапша-программер забыл своевременно освободить какой-нить сокет-листенер — и затем прога не может повторно сесть на порт новым сокетом в течении десятков минут или даже нескольких часов, если прежний сокет уже убежал во второе поколение, а нагрузка на приложуху небольшая, т.е. второе поколения не трогается GC оч долго.
Поэтому, для чувствительных к освобождению ресурсов рулит или своевременная финализация, или никакая.
Плюс, для ресурсоёмких shared-объектов иерархия владения должна быть только одностороенней, тут хорошо работает ref-counting, не зря есть объекты InspectorReferenceData, которые обслуживают этот сценарий (в несколько строк ты можешь нарисовать свои хелперы для аналогичного).
Ну и, для отложенной финализации есть классы Finalizer и NativeFinalizer, которые, в отличие от C#, надо дёргать явно, т.е. в очередь финализации попадает не каждый объект.
Тут убивается сразу два зайца:
— явное задействование механизма подразумевает, что программер продумал схему управления ресурсами для целевых объектов, т.е. что отложенная финализация для целевых ресурсов допустима;
— в очередь финализации ставятся не все объекты подряд, а лишь единичные, что делает сборку мусора резко дешевле, чем в том же C#.
Плюс еще есть WeakReference в языке, а самое главное — миксины!
Миксины позволяют реализовать различные политики управления ресурсами лишь однажды (в неких своих миниатюрных хелперах, в т.ч. которые refcount), а затем использовать их в произвольных объектах.
В C#/Джаве такой трюк невозможен, опять же.
Re[3]: Важны ли мелочи в ЯП?
Здравствуйте, Shmj, Вы писали:
S>Ну на счет квалификации — если нет встроенного механизма dispose — это не значит что теперь ресурсы станут бесконечными и вам не нужно будет об этом беспокоиться.
А это из опыта C#.
Отложенная финализация по-умолчанию — злейшее зло, как показала практика.
Этот механизм де-факто не работает, увы, хотя был разработан для сценариев, где невнимательный программист прошляпил своевременное освобождение ресурсов.
Например, лапша-программер забыл своевременно освободить какой-нить сокет-листенер — и затем прога не может повторно сесть на порт новым сокетом в течении десятков минут или даже нескольких часов, если прежний сокет уже убежал во второе поколение, а нагрузка на приложуху небольшая, т.е. второе поколения не трогается GC оч долго.
Поэтому, для чувствительных к освобождению ресурсов объектов рулит или своевременная финализация, или никакая.
Плюс, для ресурсоёмких shared-объектов иерархия владения должна быть только одностороенней, тут хорошо работает ref-counting, не зря есть объекты InspectorReferenceData, которые обслуживают этот сценарий (в несколько строк ты можешь нарисовать свои хелперы для аналогичного).
Ну и, для отложенной финализации есть классы Finalizer и NativeFinalizer, которые, в отличие от C#, надо дёргать явно, т.е. в очередь финализации попадает не каждый объект.
Тут убивается сразу два зайца:
— явное задействование механизма подразумевает, что программер продумал схему управления ресурсами для целевых объектов, т.е. что отложенная финализация для целевых ресурсов допустима;
— в очередь финализации ставятся не все объекты подряд, а лишь единичные, что делает сборку мусора резко дешевле, чем в том же C#.
Плюс еще есть WeakReference в языке, а самое главное — миксины!
Миксины позволяют реализовать различные политики управления ресурсами лишь однажды (в неких своих миниатюрных хелперах, в т.ч. которые refcount), а затем использовать их в произвольных объектах.
В C#/Джаве такой трюк невозможен, опять же.
S>Ну на счет квалификации — если нет встроенного механизма dispose — это не значит что теперь ресурсы станут бесконечными и вам не нужно будет об этом беспокоиться.
А это из опыта C#.
Отложенная финализация по-умолчанию — злейшее зло, как показала практика.
Этот механизм де-факто не работает, увы, хотя был разработан для сценариев, где невнимательный программист прошляпил своевременное освобождение ресурсов.
Например, лапша-программер забыл своевременно освободить какой-нить сокет-листенер — и затем прога не может повторно сесть на порт новым сокетом в течении десятков минут или даже нескольких часов, если прежний сокет уже убежал во второе поколение, а нагрузка на приложуху небольшая, т.е. второе поколения не трогается GC оч долго.
Поэтому, для чувствительных к освобождению ресурсов объектов рулит или своевременная финализация, или никакая.
Плюс, для ресурсоёмких shared-объектов иерархия владения должна быть только одностороенней, тут хорошо работает ref-counting, не зря есть объекты InspectorReferenceData, которые обслуживают этот сценарий (в несколько строк ты можешь нарисовать свои хелперы для аналогичного).
Ну и, для отложенной финализации есть классы Finalizer и NativeFinalizer, которые, в отличие от C#, надо дёргать явно, т.е. в очередь финализации попадает не каждый объект.
Тут убивается сразу два зайца:
— явное задействование механизма подразумевает, что программер продумал схему управления ресурсами для целевых объектов, т.е. что отложенная финализация для целевых ресурсов допустима;
— в очередь финализации ставятся не все объекты подряд, а лишь единичные, что делает сборку мусора резко дешевле, чем в том же C#.
Плюс еще есть WeakReference в языке, а самое главное — миксины!
Миксины позволяют реализовать различные политики управления ресурсами лишь однажды (в неких своих миниатюрных хелперах, в т.ч. которые refcount), а затем использовать их в произвольных объектах.
В C#/Джаве такой трюк невозможен, опять же.