Questions

I'm very pleased to be able to tell you that we've now found and fixed the problem. It was, as I suspected, because the strong name verification bypass mechanism was being broken. This happened because another facet of the obfuscation was interfering with it. We've now switched this off.

We're going to spend a little time testing the fixed build and will release it as an early access build on the homepage tomorrow.

Many thanks for your ongoing patience.

Bart

I have some good news! I ran xperf (aka Windows Performance Analyzer) to do some sampled profiling on Reflector 7.1 startup. On a 2.66GHz Xeon W3520 (basically an i7-920), it was spending 7 seconds in .... drum roll please ... strong name signature validation. clr.dll!VerifySignature() calls clr.dll!ComputeHash() and that's where all the time was being spent. (This is for a warm/cached startup. No significant disk I/O.)

The explanation:

Reflector and its dependencies have "strong names." It's kinda like a digital signature, and allows .NET assemblies to refer to each other in a more trustworthy manner (or something). If a strong named assembly is not installed into the GAC (Global Assembly Cache) then this signature must be verified every time the assembly is loaded. This involves doing a lengthy checksum/hash calculation on the whole darn thing. Every time. If the assembly is in the GAC then the system trusts that the file hasn't been tampered with and skips this computationally expensive process. If you're particularly unlucky this may also involve network access, and since this blocks the main thread it also stalls main application startup on any relevant network I/O. Using NGEN also saves time by precompiling the whole thing.

The solution: (which people can use right now, no update needed)

It's a two parter. You need to run "gacutil /i" and "ngen install" on reflector.exe and log4net.dll. NGEN is sitting in c:/windows/microsoft.net/[framework or framework64]/v4.0.30319/ngen.exe. GACUTIL is part of the Windows SDK and/or .NET SDK (should be along with Visual Studio, do a dir/s in ProgramFiles(x86)).

gacutil /i reflector.exe

gacutil /i log4net.dll

ngen install reflector.exe

(no need to do ngen install log4net.dll, as it will automatically get ngen'd when doing reflector.exe)

edit: Add RedGate.Reflector.Addin.dll to the list as well, both gacutil and ngen. You'll see a flurry of error messages; don't worry about 'em.

Once I did this, Reflector started up both qualitatively("yay faster") and quantitatively faster (xperf's data confirmed it). It could still use some more work, but it's a big step in the right direction.

I tried to find an e-mail to contact you guys but couldn't find one. Feel free to e-mail me and stuff. I work in a performance tools group in Windows, we have some knowledge in this area :)

-Rick Brewster (author of Paint.NET)

I only have 11 assemblies in my list, all of which are local. The other issue is the processor spikes to about 50-60% on every load. I'd send you a picture but not enough Karma yet :-)

-Russ

Yet more information: the delay before the window appears seems to be exclusively due to strong name verification, as suggested by a poster already. HOWEVER, .NET Reflector 6.6 is also strong named and starts up almost instantaneously. The file sizes are somewhat different - 6.6 is 2.7MB, whereas 7.2 is 4.6MB - but the delay before the window appears is disproportionately longer, even up to an order of magnitude worse, in 7.2.

This makes me suspicious. Under .NET 3.5 SP1 and later strong name verification should be bypassed for strong named assemblies that satisfy the following:

• "Fully trusted without StrongName evidence (for example, has MyComputer zone evidence)" [I quote this verbatim from the MSDN article cited below; it's one of the worst constructed statements I've ever encountered but what I think it means is that the verification is skipped where the assembly would run as full trust even if it didn't have a strong name],
• Loaded into a fully trusted AppDomain [Reflector won't even run if not run with full trust],
• Loaded from a location under the ApplicationBase property of that AppDomain [Again, this follows logically from the fact that Reflector must be runs as full trust, so must be true],
• Not delay-signed

More information is available here: http://msdn.microsoft.com/en-us/library/xwb8f617.aspx#bypassing_signature_verification.

My one slight nagging worry with this is the last point. This should not be happening, but I'll need to check with one of our build system gurus tomorrow to ensure that it isn't. If it isn't that then I'm perplexed because clearly the bypass feature is NOT working for .NET Reflector 7.2.

In addition I've noted that populating the window, once it does appear, also seems to be slightly slower if Reflector.exe has been processed with SmartAssembly. I will also investigate this although, for now, the most important issue is certainly the strong name verification.

Quick update: I've been working on other things for the past few days, however I've just had a few minutes to have another quick look at this, and I think I've found the answer (or at least am pretty close to it). I think the problem is being caused by SmartAssembly. It's not clear exactly why it's causing the slowdown yet, but I'm now at least reasonably confident that we can put together a fixed build within the next few days. I'll obviously keep you posted.

Thanks for your patience on this everyone!

Bart

This is probably due to the move to WPF. WPF apps tend to take longer to start than WinForms apps, particularly for a cold-start.

I believe .NET 4.0 has improved the startup time, but Reflector is still using the 3.5 CLR.

Thanks Richard. That may be the case, although I'm not 100% convinced - 12 seconds is a particularly long delay.

Generally I'm seeing startup times between 2 and 5 seconds on a 2 1/2 year old dual-core laptop with an Intel Centrino 2 processor - not the quickest in the world by any means. I just tested this with both 7.1.0.143 and 7.2.0.14, which is the latest dev build I pulled from our build server.

The only time I have seen startup times > 10 seconds recently is when I had an assembly in the list that was on a network share on a machine that had been shut down. At that point startup took anywhere between 10 and 40 seconds. This is because the assembly list is still, unfortunately, populated on the foreground thread - one of a list of many things we need to fix. Even in this case though, the application window would appear quite quickly, but then hang until the timeout occurred on the file access, so it wasn't as though the window simply hadn't appeared.

It might be worth checking to see if you've any non-local assemblies in your assemblies list but, if that's not the case, please let me know.

I'm also seeing very long startup times in 7.1 (longer than in 7.0). It takes about 25 seconds until it is usable (when it was started just before, so no cold-start). During this time one core of my Core2Duo 6300 is completely blocked. This is with only the default assembly list for framework 4.0 (all loaded from C:WindowsMicrosoft.netFrameworkv4.0.30319).

I'm on Windows 7 x64 SP1 with VS 2010 SP1 installed if this is important.

@russfarris @cremor

Thanks. This is very unusual. Could you both post up the contents of your Reflector.cfg files, please?

You can either find this find next to Reflector.exe, or in your local profile. The directory will be something like this:

C:\Users\{Your username}\AppData\Local\Red Gate\.NET Reflector 7

Like @cremor I also have Windows 7 x64 with VS 2010 SP1

<?xml version="1.0" encoding="utf-8" ?> <configuration> <startup> <supportedRuntime version="v4.0.30319"/> <!-- 4.0 RTM --> <supportedRuntime version="v4.0.21006"/> <!-- 4.0 Beta2 --> <supportedRuntime version="v4.0.20506"/> <!-- 4.0 Beta1 --> <supportedRuntime version="v2.0.50727"/> <!-- 2.0 RTM --> <supportedRuntime version="v2.0.50215"/> <!-- 2.0 Beta2 --> <supportedRuntime version="v2.0.50110"/> <!-- 2.0 PD7 --> <supportedRuntime version="v2.0.40903"/> <!-- 2.0 PD6 --> <supportedRuntime version="v2.0.40607"/> <!-- 2.0 Beta1 --> <supportedRuntime version="v2.0.40426"/> <!-- 2.0 PD5 --> <supportedRuntime version="v2.0.40301"/> <!-- 2.0 PD4 --> <supportedRuntime version="v2.0.40209"/> <!-- 2.0 PD3 --> <supportedRuntime version="v2.0.31113"/> <!-- 2.0 PD2 --> <supportedRuntime version="v2.0.31010"/> <!-- 2.0 PD1 --> <supportedRuntime version="v1.2.30703"/> <!-- 2.0 PDC --> <supportedRuntime version="v1.1.4322"/> <!-- 1.1 RTM --> <supportedRuntime version="v1.0.3705"/> <!-- 1.0 RTM --> </startup> <runtime> <loadFromRemoteSources enabled="true" /> <generatePublisherEvidence enabled="false"/> </runtime> </configuration>