x

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Topics:

x4

asked: May 11 '11 at 06:13 PM

Seen: 5120 times

Last Updated: May 11 '11 at 06:13 PM

It seems the latest version (7.1.0.143) is much slower than the previous version. It takes approximately 12 seconds to load. There times when I open the app I'm not sure if it really started and end up opening 2-3 instances.

Is this normal?
more ▼
asked May 11 '11 at 06:13 PM russfarris 71 russfarris gravatar image
(comments are locked)
10|600 characters needed characters left

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
more ▼

answered Jun 09 '11 at 05:44 PM

Bart gravatar image

Bart ♦♦
604 3 10

cremor gravatar image cremor Jun 09 '11 at 07:47 PM

Great, looking forward to it.

PS: Sorry for the delay about the remote debugging but I didn't have time to prepare it yet. Hopefully it won't be needed any more now :)
Bart gravatar image Bart ♦♦ Jun 10 '11 at 02:32 PM
This has now been uploaded. Thanks again for your patience, and sorry for the hassle.
russfarris gravatar image russfarris Jun 13 '11 at 04:33 PM
@Bart just downloaded the new EA3 and the laod time is MUCH improved. Takes about 3.5 seconds to load now.
cremor gravatar image cremor Jun 14 '11 at 06:43 AM
EA3 starts in 5 seconds now for me, great! Many thanks for your work!
Bart gravatar image Bart ♦♦ Jun 15 '11 at 10:44 PM
Great, glad to have got to the bottom of it at last. Thanks for letting me know!
(comments are locked)
10|600 characters needed characters left

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)
more ▼

answered Jun 02 '11 at 09:44 PM

RickBrewster gravatar image

RickBrewster
61 1 6

Bart gravatar image Bart ♦♦ Jun 03 '11 at 12:02 AM
Legend! Thanks Rick! I suspect that'll certainly help, although in the case of @cremor I still think there's something we're missing. He's seeing a 20 second start-up time which, unless he's running on a Commodore 64, is completely ridiculous. I've asked both @cremor and @RussFarris to try out your suggestion so we'll see what difference it makes soon enough, I hope.
RickBrewster gravatar image RickBrewster Jun 03 '11 at 12:23 AM

Like I said, e-mail me :) My group is in the business of performance, and we even have experience making WPF stuff fast (as well as C#, .NET, and WinForms).

A simple fix on your end could be to simply not use strong naming. Unless this is required for your licensing system, there isn't really a good reason to do it. Strong naming and GAC is mostly for system-wide shared libraries. Like System.Core.dll or ICSharpCode.SharpZipLib.dll, or maybe some web server stuff.
russfarris gravatar image russfarris Jun 03 '11 at 12:26 AM

I ran the following from the command prompt:

gacutil /if c:\reflector\reflector.exe gacutil /if c:\reflector\log4net.dll gacutil /if c:\reflector\RedGate.Reflector.Addin.dll ngen install c:\reflector\reflector.exe ngen install c:\reflector\RedGate.Reflector.Addin.dll

There was no difference in startup. Am I missing something?
RickBrewster gravatar image RickBrewster Jun 03 '11 at 12:30 AM

Don't forget log4net.dll

Also, you can verify that gacutil worked by going to c:/windows/assembly. It'll show up in the list.
russfarris gravatar image russfarris Jun 03 '11 at 12:36 AM

Two things:

1) on an x64 system you have to run the x64 command prompt (duh) 2) It cut it down to about a 5 second load time
(comments are locked)
10|600 characters needed characters left

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
more ▼

answered May 11 '11 at 07:29 PM

russfarris gravatar image

russfarris
71 2 3 9

(comments are locked)
10|600 characters needed characters left

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.

more ▼

answered Jun 08 '11 at 08:39 PM

Bart gravatar image

Bart ♦♦
604 3 10

(comments are locked)
10|600 characters needed characters left

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

more ▼

answered Jun 08 '11 at 04:17 PM

Bart gravatar image

Bart ♦♦
604 3 10

(comments are locked)
10|600 characters needed characters left

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.
more ▼

answered May 11 '11 at 06:35 PM

RichardD gravatar image

RichardD
106 7 13 25

(comments are locked)
10|600 characters needed characters left

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.
more ▼

answered May 11 '11 at 07:04 PM

Bart gravatar image

Bart ♦♦
604 3 10

(comments are locked)
10|600 characters needed characters left

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:\Windows\Microsoft.net\Framework\v4.0.30319).

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

answered May 12 '11 at 09:19 AM

cremor gravatar image

cremor
159 6 8 21

(comments are locked)
10|600 characters needed characters left

@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

more ▼

answered May 12 '11 at 01:13 PM

Bart gravatar image

Bart ♦♦
604 3 10

(comments are locked)
10|600 characters needed characters left

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>
more ▼

answered May 12 '11 at 03:32 PM

russfarris gravatar image

russfarris
71 2 3 9

Bart gravatar image Bart ♦♦ May 12 '11 at 03:43 PM
Hi Russ, Sorry - that's not it - that's the Reflector.exe.config file. The file I need is Reflector.cfg, which has a list of assemblies in it, along with a load of other configuration information. Try looking in your local profile under C:\Users\{Your username}\AppData\Local\Red Gate\.NET Reflector 7 Thanks, Bart
russfarris gravatar image russfarris May 13 '11 at 06:08 PM

Sorry bart. Misunderstood:

http://pastebin.com/7K1h89VU
Bart gravatar image Bart ♦♦ May 17 '11 at 01:43 PM
No probs. Thanks Russ!
(comments are locked)
10|600 characters needed characters left
Your answer
osqa.question.ask.tags.preview.show

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.