Options
Time taken to obfuscate
nyxling
Posts: 9
Our team has been using SA for about a year now, and we've noticed that the amount of time it has taken to obfuscate has been increasing fairly dramatically during this time. We're looking for a way to speed up our build, or at least an explanation of why it's taking so much longer now than before.
When we first started using SA, we took some time to find some settings we liked, and haven't changed them since (except for exclusions), and it took (from memory) about 5-10mins to obfuscate our 2mb DLL, start to finish. During the year, we've fairly frequently gone into the exclusion list (which takes just a long to populate as the regular obfuscation build, btw-- why does it need to obfuscate to bring up this list?) and added more exclusions.
Our most recent obfuscation builds take on the order of 2.5hrs to build our 3.5mb DLL, start to finish- which is getting pretty ridiculous.
Our first thought was that our fairly extensive exclusion list was slowing it down, since we have been consistently adding to it throughout the year, so we tried cleaning out all of our method exclusions since we've since dealt with them in the source code itself, and the exclusions in SA were just remaining there as a "fail safe", if anything. However, it appears that this cleansing of the SA project file didn't actually achieve anything for us regarding build time.
What else could be causing it to take so long? Are there other things we can do to help narrow down where the time is being spent? Do we have other options to speed it up, such as adding more cores/ram/etc to the system doing the builds?
When we first started using SA, we took some time to find some settings we liked, and haven't changed them since (except for exclusions), and it took (from memory) about 5-10mins to obfuscate our 2mb DLL, start to finish. During the year, we've fairly frequently gone into the exclusion list (which takes just a long to populate as the regular obfuscation build, btw-- why does it need to obfuscate to bring up this list?) and added more exclusions.
Our most recent obfuscation builds take on the order of 2.5hrs to build our 3.5mb DLL, start to finish- which is getting pretty ridiculous.
Our first thought was that our fairly extensive exclusion list was slowing it down, since we have been consistently adding to it throughout the year, so we tried cleaning out all of our method exclusions since we've since dealt with them in the source code itself, and the exclusions in SA were just remaining there as a "fail safe", if anything. However, it appears that this cleansing of the SA project file didn't actually achieve anything for us regarding build time.
What else could be causing it to take so long? Are there other things we can do to help narrow down where the time is being spent? Do we have other options to speed it up, such as adding more cores/ram/etc to the system doing the builds?
Comments
Sorry to hear you're running into an issue with SmartAssembly!
There is one SmartAssembly 6.8 bug I know of that could cause builds to slow down immensely. It occurs when your assembly or one of its dependencies relies on the .NET 1.1 framework (SmartAssembly takes a long time to resolve the 1.1 libraries).
To first check if this is the issue, could you please:
- Enable logging on SmartAssembly - http://documentation.red-gate.com/displ ... rtAssembly
- Restart SmartAssembly, open your project and start building your application
- You can just let it run for 5-10 minutes or so, then take a look at the log file (%LocalAppData%\Red Gate\SmartAssembly 6\SmartAssembly.log )
Does the log file show SA trying to resolve any 1.0.xxxx.x version or mscorlib?
i.e.
Resolved assembly {mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089}
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?
Thanks for the reply!
I went thru your steps and opened up the log file after a few minutes-- when looking at the Resolved Assembly lines, the only instances of Version=1. I found were for some of our third party assemblies. All of the lines for mscorlib were Version=2.0.0.0.
Added information: During a build, the progress bar goes up to about 33% pretty quickly (a minute or two), but at that point, the text changes to Obfuscating..., and then 99% of the time building is spent getting from that point to about 49% (the text doesn't change during that whole time). After that, the progress bar moves pretty quick again, to finish it off within a few minutes.
Currently using SA Version 6.8.0.121
Thanks for checking that! If it's not the .NET 1.1 issue, can I please check--is SmartAssembly using a lot of cpu and/or memory during the Obfuscating step?
Have you tried building on another machine to see if that makes any difference?
I'm going to send you an email through the open support ticket we have opened for you (#16586)--would you mind replying with the contents of your log file so we can take a look for anything interesting there?
If it's also possible to get a copy of your assembly and its dependencies to try and reproduce this slowness locally, that would be much appreciated! (though I realize that sharing may not be an option)
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?
I sat thru the first 15 minutes of obfuscation, looking at the task in Process Monitor, and it appears that CPU and RAM usage is not an issue:
* CPU was pretty consistently at 12.5% (and the System Idle Process had about 85%)
* RAM was mostly at about 220MB
It will take me some time to run thru another build again, to get a full log file for you, since it takes 2.5hr or so to do. I'll try to remember to set it to run tonight, on my way out of the office.
Unsure about whether I'll be able to share the assembly with you or not, but I strongly suspect there will be non-trivial resistance from management on the subject, so it's probably best if we left exploring that option as a last resort.
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?