Улучшение характеристик локализации? (ComponentResourceManager.ApplyResources)

Question

После того, как возникли некоторые проблемы с производительностью на моей стороне клиента, мы решили попробовать некоторые из профилировщиков производительности, чтобы попытаться найти узкое место или идентифицировать виновные части кода. Конечно, как и многие исследования эффективности, проблемы возникают из разных вещей, но что-то я выясняю в том, что ComponentResourceManager.ApplyResources моих пользовательских элементов управления занимает слишком много времени при построении моих форм: более 24% времени строительства проведенных в ApplyResources внутри InitializeComponent(). Это кажется довольно много для «поиска строки ресурса и помещения его в контейнер».

Что конкретно сделано в ComponentResourceManager.ApplyResources? Я предполагаю больше, чем поиск строки, если бы не так долго.

Есть ли способ улучшить характеристики локализации? Наше программное обеспечение локализовано на нескольких языках, поэтому нам нужно сохранить эту многоязычную функцию.

Любые рекомендации по этой проблеме?

Спасибо!

PS: Мы кодируем в C#, .NET 3.5 SP1.

Answer 1

Метод ApplyResources использует отражение найти свойства, которые будут обновлены со значениями ресурсов:

property = value.GetType().GetProperty(name, bindingAttr);

Отражение, как известно, медленно. Назначьте значения ресурсов вручную для свойств (например, используя ResourceManager.GetString(...)). Это утомительно для кода, но должно улучшить производительность.

Answer 2

Я бы захватил отражатель и посмотрел метод ApplyResources, чтобы увидеть, что он на самом деле делает.

Я бы также рекомендовал профилирование с использованием JetBrains dotTrace 4 (в настоящее время в EAP, но испытания могут быть загружены), так как он также может показывать время, проведенное внутри системных классов. Это делает его гораздо более прозрачным, когда время фактически расходуется. Например, вы можете узнать, потрачено ли время на поиск ключей в словаре, доступ к файлам и т. Д.

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