Telerik blogs

We began the development cycle with one primary goal: make JustDecompile a flawless, shining example of software engineering. We knew it was a pie in sky goal to complete in only a few a months, but to capture the moon you must reach for the stars.

And capture the moon we did. Our tests show that against the .NET Framework 4, JustDecompile is the fastest decompiler for .NET.

The skeptics among you may have noticed my word usage leaves wiggle room. To be clear, it is possible a decompiler no one has ever heard of beats us at decompiling a .NET 2.0 application modified with IL injection. Exhausting every possible combination isn’t productive, and we originally just needed a measure of our progress. To accomplish this, we compiled a list of well-known decompilers and culled ones that had no public means of automation. The lack of automation greatly hinders one’s ability to decompile an entire assembly and retrieve the time lapse, and it certainly wouldn’t be fast for a user. We also needed to prevent bias from programming style and other factors affecting the compiled byte code. Therefore, we targeted the edition of the .NET Framework in common usage at the beginning of our development cycle.

Were we the best at the beginning? It was a mixed bag. We were more correct with some assemblies and faster with others. To ensure JustDecompile is the best choice for the majority of .NET applications, we focused on the average speed and full error count over the entire framework. We weren’t winning, but we weren’t losing either.

I don’t want to say that increasing the accuracy of the decompiled code was easy. JustDecompile is one of the more recent products at Telerik. However, our team is excellent, and most inaccuracies are due to edge cases. Fixing them is a matter of finding those edge cases, determining why the compiler produced the sampled IL, and then finding a way to represent that IL like, if not exactly like, the original code.

The accuracy challenge began as a known quantity. Meanwhile, we faced another challenge to increase JustDecompile’s performance, and the solution was just down the hall at Telerik HQ.

Funny story: JustTrace already uses the JustDecompile engine.

The Wizard Ninjas aided the Spartan Ninjas in their quest for superiority. Pounds (kilos) were shed, muscles were cut, and Nicholas Cage filmed yet another movie (or two) no one watched. The leaner, meaner JustDecompile came out of training just last week.

Opening one of my web projects, I pulled out WebGrease.dll. My goal was to make the decompilers cry, and WebGrease happened to be the largest assembly in my bin directory. JustDecompile decompiled the entire assembly in 4.8 seconds. That doesn’t sound impressive, but it decompiled the much smaller AutoMapper in 0.1 seconds.

I am aware of only two other decompilers that can do an entire assembly at once. The first one I tested handled the assembly in 5.6 seconds, but there was an additional second or two beyond when it “finished” and the screen unlocked (note: if you’re experiencing similar behavior in your apps, upgrade to C# 5 and take advantage of async/await).

The second decompiler took ~50 seconds before it completed.

Using the C# compiler to measure errors wasn’t much help since it always gave up after a small number of errors. I turned to JustCode to obtain a thorough analysis. It found 207 errors in the JustDecompile output, mostly related to Code Contracts attributes. That certainly does not look good, but it’s far better than the 7947 and 8501 errors from the other products. Both made a fundamental mistake: not including the references in the output. I’m more interested in the quality of code output, so I quickly fixed the issue by adding a reference. Seconds later, I was able to see the pattern matching errors: 305 for one and 833 for the other. These errors included labelled, fall-through switch statements and other difficult-to-correct constructs.

The JustDecompile development team did an amazing job. They’ve released a free product that outperforms everyone else. 

There’s still some room for improvement. We may have captured the moon, but we’re still aiming for the stars


About the Author

Chris Eargle

is a Microsoft C# MVP with over a decade of experience designing and developing enterprise applications, and he runs the local .NET User Group: the Columbia Enterprise Developers Guild. He is a frequent guest of conferences and community events promoting best practices and new technologies. Chris is a native Carolinian; his family settled the Dutch Form region of South Carolina in 1752. He currently resides in Columbia with his wife, Binyue, his dog, Laika, and his three cats: Meeko, Tigger, and Sookie. Amazingly, they all get along... except for Meeko, who is by no means meek.

Comments

Comments are disabled in preview mode.