Комментарии 7
А ещё удивительный факт, но если обернуть вызов функции в лямбду, то она уже будет кэшироваться.
Это method group conversion, да. Долго не хотели менять, чтобы не сломать совместимость со спецификацией компилятора, но в конце концов сделали хотя бы для статических методов.
Спасибо что рассказли новичкам, что аргументы, которые выглядят как методы, передаются в виде объектов, которые, если их специально не создавать заранее, действительно будут создаваться каждый раз заново, и если это происходит часто - излишне грузить сборщик мусора.
Жаль, что не рассказали, что этот сорт объектов (к нему, в частности, относятся определенные в библиотеке времени выполнения обобщенные типы Func и Action с различным числом аргументов-типов) в C# называется "делегаты" (delegates): знание правильных имен сущностей языка сильно помогает при поиске в документации. Ну, и что можно встретиться с другими типами-делегатами, не толкько со специализациями Action/Func: например, при реализации самодельных объектов-обработчиков (middleware) для конвейера веб-приложения на ASP.NET Core обязательно придется столкнуться с делегатом типа RequestDelegate
Спасибо за акцент на том, что можно улучшить. Постараюсь учесть это в новых статьях. А может даже и при переносе на Хабр тех, что уже готовы.
Возможно, это не самое правильное поведение, но я намеренно хотел сделать акцент на методах познания мира .Net, на интересном погружении внутрь всяких мелочей, начиная с чего-то простого и жизненного. Чтобы "выводить интересности на ходу". И не хотелось заваливать терминологией. Но я соглашусь, что называть вещи своими именами (по крайней мере в конце, когда всё стало понятно) важно.
Может слегка не по теме, и ситуация была чуть попроще, но я (все еще отношу себя к "новичкам", к сожалению...) столкнулся с близкой проблемой:
Пытался из "подсмотренного" кода на С++ переписать на C# UserControl типа радиальный градиентный HeatMap.
RadialDiagram
А так как я все еще начинающий - то очень часто лезу за примерами в инет. Например, так как я до этого на формах в своих программах еще не рисовал (только пользовался готовыми контролами) то и делал, как советуют во всяких туториалах.
В первом приближении получилось, но мерцание и подтормаживание при перерисовке были заметны, что слегка омрачило первые радостные эмоции от заработавшего контрола.
Если вкратце - профилировщик показал огроменное количество созданных объектов Pen. К счастью, очень быстро все поправил, т.к. практически, единственное место в коде где создавался объект Pen был цикл в котором перебирались данные, на основании которых строилась диаграмма. После того как вынес создание Pen перед циклом, а в цикле только менял его свойства (цвет) - все стало намного шустрее.
Отличный пример использования инструмента анализа эффективности работы приложения на практике! Факт наличия проблемы замечен -> нашли источник проблемы -> исправили -> подтвердили, что всё стало лучше. Без шуток, вы молодец.
Да, тема статьи немного не об этом, но механика "ухудшения производительности приложения" через "ненужный спам объектов" одинаковая. Просто в вашем случае это было более явно (сами сделали new), чем в ситуации, описанной в статье (сахар в языке скрыл от нас new).
А самое веселье начинается, когда такое передают как коллбэк нативному методу (в C/C++).
Особенно радостно поймать SIGSEGV, потому что в какой-то момент GC успел-таки прийти за делегатом...
Сказка про Method as Parameter