R# 3.5 Development Suggestion: Performance Enhancer

I have been a user of R# since 1.5 days and love the edge and insight it gives me into my code. One persistent thorn is everyone's side is performance on load of a new solution.

Since the 2.0 Betas it has been agonizingly slow. It is considerably better now, but I think I have a partial solution to the problem on load. The current load progress bar denotes the assemblies that it is parsing, and undoubtedly every start up, it always parses mscorlib, System.Data, etc.

My thought is: why not keep a cached assembly list with MD5 or other hash of existing libraries referenced in a project. Then you can utilize the list with existing caches to keep from reparsing the same libraries repeatedly.

The workflow might proceed as follows:

- Load cached list of already-parsed assemblies (with MD5 Hashes)
- Get references in solution
- Compute MD5 Hash on each reference
- Check preparsed list to see if assembly has already been parsed and if the md5 hash matches.
- If matched, then use the preparsed cache, instead of reparsing
- If not matched, parse the assembly
- Add it to cache
- Add the assembly MD5 hash to the cached list for later use

Then make sure you add a button to dump the caches (or just hook it to the one you already have so that you can clear the caches)

Then at most you'll have to re-parse all the assemblies once, and then only when they change thereafter, significantly reducing startup time (I would suspect)

The only downfall is that if you are using a unified cache for all the assmblies in a project, then you may have to cache them as fragments and assemble the whole as part of the process.

You might even consider bloating the installer a bit and pre-loading a set of caches for the entire .NET framework segmented by assembly and release (it is likely that most people will have the .NET released version frameworks like 1.0.3705, 1.1.4322, 2.0.50727, 3.0)

Any comments anyone?

Ciao

2 comments
Comment actions Permalink

Actually, the assembly metadata is cached.
The notification window says "Parsing assembly.....", but usually it loads
it from cache - the message is one for all cases

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Chadwick Posey" <chadwick.posey@gartner.com> wrote in message
news:14619412.1180797491958.JavaMail.itn@is.intellij.net...
>I have been a user of R# since 1.5 days and love the edge and insight it
>gives me into my code. One persistent thorn is everyone's side is
>performance on load of a new solution.
>

Since the 2.0 Betas it has been agonizingly slow. It is considerably
better now, but I think I have a partial solution to the problem on load.
The current load progress bar denotes the assemblies that it is parsing,
and undoubtedly every start up, it always parses mscorlib, System.Data,
etc.

>

My thought is: why not keep a cached assembly list with MD5 or other hash
of existing libraries referenced in a project. Then you can utilize the
list with existing caches to keep from reparsing the same libraries
repeatedly.

>

The workflow might proceed as follows:

>

- Load cached list of already-parsed assemblies (with MD5 Hashes)
- Get references in solution
- Compute MD5 Hash on each reference
- Check preparsed list to see if assembly has already been parsed and if
the md5 hash matches.
- If matched, then use the preparsed cache, instead of reparsing
- If not matched, parse the assembly
- Add it to cache
- Add the assembly MD5 hash to the cached list for later use

>

Then make sure you add a button to dump the caches (or just hook it to the
one you already have so that you can clear the caches)

>

Then at most you'll have to re-parse all the assemblies once, and then
only when they change thereafter, significantly reducing startup time (I
would suspect)

>

The only downfall is that if you are using a unified cache for all the
assmblies in a project, then you may have to cache them as fragments and
assemble the whole as part of the process.

>

You might even consider bloating the installer a bit and pre-loading a set
of caches for the entire .NET framework segmented by assembly and release
(it is likely that most people will have the .NET released version
frameworks like 1.0.3705, 1.1.4322, 2.0.50727, 3.0)

>

Any comments anyone?

>

Ciao



0
Comment actions Permalink

Actually, the assembly metadata is cached.
The notification window says "Parsing assembly.....", but usually it
loads
it from cache - the message is one for all cases


Perhaps you should consider a more informative message - your users are developers
and will wonder
why you parse the metadata every time. It's not enough to BE smart - you
also have to look smart :)


0

Please sign in to leave a comment.