Why does performance suffer after encrypting assemblies using AxProtector .NET?

Share:

This performance loss is a known issue. It occurs because your original code is "moved" to a secure place, and AxProtector code is placed at the original address when encrypting your assembly with AxProtector .NET.

If you now run your encrypted assembly and the method, which you encrypted, is called, only this AxProtector code is found. This AxProtector code redirects to the place at which the encrypted original code is stored. This code is then decrypted, and a dynamic method is created and executed.

As a result, the first calling-up of your encrypted method takes about 1.2 - 1.5 ms longer. This behavior also depends on the hardware setup of the PC on which the assembly is executed.

If your method is called a second time, this takes approx. 8 - 10 µs longer (generic methods take 30-60 µs longer), because the AxProtector code is executed again. However, AxProtector now checks, whether the method has been decrypted before. If this is the case, it redirects to the already encrypted code.

However, the performance loss is also largely determined by how often individual methods are called. For example calling a method 5,000,000 times adds up to 40 seconds, given 8 µs for each call.

Methods called this often typically hold no elementary code. You can regain performance, if you exclude such method from encryption. By default, we automatically exclude all methods smaller than 10 bytes. You can also customize the size of the excluded methods. This is done via the AxProtector option "-CMLn", which defines that only methods smaller than n bytes are encrypted.

In order to find out which methods are called frequently by an assembly, we recommend using a .NET profiling tool. These tools give detailed information on the methods called and the time required. Based on this data, you can decide which methods should be encrypted.

To top