Speeding up obfuscation process
Asked Answered
M

1

4

So, I've got a moderately to significantly complicated WPF application that I've got a requirement to obfuscate the output assemblies via Dotfuscator (pro edition - the one the client has a license for).

Three issues:

  • The obfuscation process crashes with an OutOfMemoryException approximately 85% of the time
  • It takes a LONG time - the average obfuscation pass takes about 56 minutes to complete
  • There are a whole heap of various issues that cause the app to crash with the obfuscated assemblies, from reflection-based lookups to resources.

The first problem I've been able to mitigate by running via the command line as opposed to the GUI (it doesn't crash, at least), and the third wouldn't be that big of an issue if I could quickly iterate over combinations of options instead of maybe getting 5 attempts per working day.

It's really the total time that's killing me; anyone aware of any "quick-fix" ideas to dramatically improve the time taken for obfuscation? Is it possible some goofy thing I've done is causing some sort of "Vapor-lock" during the process, increasing the processing time? Do I need to press the client to use a different obfuscator?

Some details:

  • Approx. 38 assemblies/exes in the application (of which maybe 5-10 are third party dlls marked as 'artifact' so they don't get obfuscated)
  • The box is a semi-beefy physical server, not a VM.
  • I'm using a config file to drive the obfuscator as opposed to processing each assembly individually.
  • I've already marked a number of excludes in said config file for things like generated Resources
  • All assemblies are marked as 'library'

Any thoughts and/or SWAGs would be most appreciated.

Medardas answered 30/4, 2013 at 21:30 Comment(3)
I'm not personally familiar with the software, but it sounds like you need RAM... and a lot of it. I'm thinking the slowness is from the OS swapping/using virtual memory. RAM is cheap these days. And maybe a SSD or two...?Nasser
@StevenVondruska Yeah, that was my first thought as well...I've already got a request in to get more memory for the box, but that'll take time to get processed and fulfilled (ah, bureaucracy). For what it's worth, using the command line it's only hovering around 500 MB usage.Medardas
What are the specs of this system and are you using a 32bit or 64bit OS?Influential
I
1

You need more memory most likely. Dotfuscator isn't exactly lightweight in memory when running through large projects. I'd recommend 2 gigs as a minimum for most projects, and 4 gigs preferable. Also, it might run faster under 64-bit, due to the extra virtual memory space. Also, you might want to ensure that you're losing the latest version of Dotfuscator, since there have been some performance improvements between releases in the past

Excludes usually won't speed up Dotfuscator significantly unless you're excluding whole assemblies.

Influential answered 1/5, 2013 at 14:17 Comment(4)
Thanks Earlz, as I mentioned to Steven, I had a sneaking suspicion that memory was a factor - it's a 4 gig box already, however. I'll be sure to check the version, however - it's very likely we're not on the "current" one. If that improves things, I'll mark this.Medardas
Oh, interesting - is this still a "viable hack"? #15823104Medardas
I won't say it's supported, but it should work :) That only applies if you can split your project up (which doesn't sound like it's possible since I assume everything relies on everything)Influential
Switched to a different machine and jumped three versions to current and things appear significantly faster. Not perfect, but FAR more reasonable!Medardas

© 2022 - 2024 — McMap. All rights reserved.