What are the challenges you face when working across database platforms? Take the survey

The runtime cost of obfuscation

MorantexMorantex Posts: 10
edited June 28, 2013 7:34AM in SmartAssembly
I've been running some performance measurements here on code that is obfuscated and comparing it code that is not.

Basically a test client/server is used to stress test a managed networking API - one that is wholly message based (as opposed to primitive sockets and their byte[] blocks).

This code does a lot - custom (v fast) serialization and intelligent buffering, message dismantling/reassembly and so on and a lot of work and extensive profiling has gone into making this very fast.

Several test clients randomly exchange hundreds of thousands of messages with a test server and we look at total per-process CPU against number of messages.

Here is what I am seeing on tests that run for approx 1 minute elapsed time:

Debug build w obfuscation: 75 uS / msg
Release build w obfuscation: 73 uS / msg.
Debug build n obfuscation: 60 uS / msg.
Release build n obfuscation: 50 uS / msg.

Now since RedGate supply both an obfuscator and a profiler - I'd very much like someone to tell me what specific obfuscation choices cause the most runtime CPU penalties.

I could spend hours tweaking various settings but there are numerous assemblies involved here and each one has its own SA project file, and an SA project supports a host of differing choices and combinations for them- so frankly this is a non-starter (I may disable string oriented settings as a quick experiment though).

What's clear here is that obfuscation of release build code can lead to code that runs slower than an ordinary debug build of that code.

In this case it's adding about 50% more CPU cost over the cost of "pure" release build code - and for a high performance API this is a big cost that undermines all of the original profiling effort.

So RedGate - how can you offer a product that helps us speed up code then at the same time offer us another product that slows it down again !




  • Options
    UPDATE: Disabling the dynamic proxy option on two of the more relevant assemblies here saw the 73 uS/msg fall to 65 uS/msg. (That is an obfuscated release build) but this is still performing worse than a straightforward debug build.

  • Options
    Control-flow obfuscation.

    That's the feature that we know causes systematic slow-down.

    Empirical evidence suggest level 2 (strictly valid) has least effect.
Sign In or Register to comment.