После шифрования сборки с использованием AxProtector .NET появляются проблемы с производительностью. Почему?

Поделиться

Проблема с производительностью известна. Причина в том, что в процессе шифрования сборки при помощи AxProtector .NET код приложения перемещается в секцию безопасности, и в исходном адресе появляется код AxProtector.

Если запустить зашифрованную сборку и вызвать зашифрованный метод, то в первую очередь будет найден код AxProtector. Этот код перенаправит вызов в секцию, где находится исходный зашифрованный код. После чего код будет расшифрован, и будет создан и запущен динамический метод.

Поэтому первый вызов защищенного метода происходит на 1,2 - 1,5 мс дольше. Это также зависит от аппаратной конфигурации ПК, на котором запускается сборка.

Второй вызов метода происходит на 8 - 10 мкс дольше (генерируемые методы происходят на 30-60 мкс дольше), потому что код AxProtector будет запущен снова. На текущий момент AxProtector проверяет расшифровывался ли метод раньше. Если расшифровывался, то сразу же произойдет перенаправление к уже зашифрованному коду.

Потеря производительности также определяется количеством вызовов конкретных методов. Например, вызов метода 5,000,000 раз добавляет до 40 секунд с учетом 8 мкс для каждого вызова.

Методы, вызываемые наиболее часто, не хранят элементарного кода. Производительность повышается, если не шифровать такие методы. По умолчанию мы автоматически исключаем все методы, которые весят меньше 10 байт. Но это можно изменить, указав нужный размер для исключаемых методов. Для этого используется опция AxProtector "-CMLn". Тогда шифроваться будут только те методы, которые имеют размер менее, чем n байт.

Для того чтобы найти наиболее часто вызываемые сборкой методы, мы рекомендуем использовать .NET profiling tool. Эти утилиты показывают детальную информацию о вызываемых методах и затрачиваемом на вызов времени. На основе этих данных Вы решаете какие методы шифруются, а какие остаются незашифрованными.

To top