Performance Considerations

Some obfuscation techniques inevitably add a performance overhead. Of the available features in Jigsaw, the two techniques that could cause performance problems are control flow abstraction and integrity checking. The following graph illustrates the effect of these two techniques on a CPU intensive benchmark app:

The top-most green line represents a checksum level of 100%. If the control flow level is also set to 100%, then you can expect a 3.7x slowdown in the speed of the app. The default values of 50% and 30% should result in a slowdown of around 1.6x (i.e., 60% slower than the unprotected app).

Given that most apps tend to spend time waiting on user input or networking, it’s unlikely that this level of slowdown will be noticed. However, you still might want to consider the following points:

• If you are using any time-critical open source libraries (e.g., Tensorflow, OpenCV, libTorch, etc.), it would have little security  effect to completely exclude them from Jigsaw. If you do want to tie them into the app, then you could use section  encryption (and only section encryption), which would have zero impact  on runtime performance.

• If you have time-critical security code (e.g., crypto libraries where  large cryptographic operations are performed), then you will want to  ensure that entry points and key handling are very well protected but  any symmetric cipher code and block operations are still fast. In this case, you should create a custom configuration file with  sections to direct where to place the protection and at what level. Recommendations would be close to 100% in entry points and around 20% in  the actual cipher code. You should exclude those symbols from checksum placement, as well.

• For most apps, the defaults should give reasonable performance. If performance is not an issue to begin with, then consider upping the  protection levels to increase coverage and improve security.