Why are new OutOfMemoryException bug reports marked as fixed?

I know the memory footprint of RS is a big issue in the upcoming 4.5 release. But the out of memory issue is pretty severe and doesn't really seem to be improving in the latest nightlies. In fact, if anything, the number of out of memory reports in the RS bug tracker is less than the number of actual occurrences.

So I was wondering about the methodology. Why are all these new exceptions being marked as fixed in the bug tracker, despite this issue's continued prominence?

Curious,
Noam

3 comments

Hello Noam,

They are marked as Closed with the resolution Duplicate. There is no reason
keeping all of them open. We are aware of the issue very well, and probably
know more than anyone else about memory model of VS running with managed
add-ins and packages. Unfortunately, there is no cure right now and it is
actually a matter of project size and number of things installed into VS.
There are some ideas about resolving the issue at its core, but those require
so much work that we cannot tell when it can be done. On the other hand,
ReSharper can chew projects of much larger sizes than any other add-in which
needs code model, of which there are few on the market ;)

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


IR> I know the memory footprint of RS is a big issue in the upcoming 4.5
IR> release. But the out of memory issue is pretty severe and doesn't
IR> really seem to be improving in the latest nightlies. In fact, if
IR> anything, the number of out of memory reports in the RS bug tracker
IR> is less than the number of actua
IR>
IR> l occurrences.
IR>
IR> So I was wondering about the methodology. Why are all these new
IR> exceptions being marked as fixed in the bug tracker, despite this
IR> issue's continued prominence?
IR>
IR> Curious,
IR> Noam
IR> ---
IR> Original message URL:
IR> http://www.jetbrains.net/devnet/message/5233078#5233078


0

We're currently looking into options to alleviate this issue. It's becoming a more and more significant drain on productivity. At a rough guesstimate, we figure that we're losing about 20% productivity because of OutOfMemory exceptions related to RS: shutting down VS, restarting it, reloading the solution, having RS load all its data into the various caches, grabbing a smoke or a drink in the mean time, and then getting back to work. And it seems like the more tooling we use (unit testing, stack traces, find results, fund symbols, navigation aids, etc.), the more often it happens.

Truth be told, the out of memory issue is more critical to us than all the other issues put together. It's more critical than bugs that crash VS and even bugs that delete our code (we've got source control!), never mind new quick fixes and contextual options and support for new language constructs and whatnot. RS obviously isn't the only productivity drain, but it is significant. So much so that some of our programmers are disabling RS on their machine by default and then enabling the add-in only occassionally, for specific purposes, or even ditching it altogether. New programmers that join the team really want RS when they see what it can do, but only after it "starts working right".

So we're looking into various options for reducing the memory footprint and overcoming this hurdle, so we can work more productively with RS. Were looking
1. Do you have any metrics for what constitutes a healthy "project size", should we choose to split up our large solutions?
2. Is it the number of code constructs (classes, interfaces, enums, etc.), lines of code, number of files, file size or some other measure that most affects RS?
3. Is the issue affected more by the number of projects or by their size?
4. If we were to hypothetically split the solution up into 2 solutions and open each in a separate VS side-by-side on a duo or quad machine, would that help (since each would reside at runtime in its own 2GB address space)?

Do you have any ideas, tools or recommendations for reducing the memory footprint, in the mean time? Any case studies, by any chance, or solid metrics you can publish?

Thanks!

0

Hello Noam,

There could be several possible cases. Either your solution is really large
(like ReSharper is 100 projects with 10K files approx, and we are getting
problems with OOM ourselves), or you have Web Site project (this approx doubles
memory usage due to code generation we do in background), or you have something
special about your solution which causes extreme memory usage by ReSharper.

If you have large solution, you can try the following:

  • use Vista x64, which gives more than 3Gb even to 32bit processes and have

some improvements in memory allocation for loaded modules (DLLs).

It is actually a hack for some memory allocation problems in Windows, so
use carefully.

  • use /3G switch for OS booting, but that can cause issues with drivers not

designed to support this flag

If you have Web Site, you can try ReSharper 4.5 nightlies, which should have
improved memory usage for large web sites.

If neither of this helps, contact me directly (orangy at jetbrains) and we
can discuss and may be do remote memory profiling session to understand the
issue.

Btw, if you enable Memory Indicator in ReSharper (Options / Environment /
General), what would be typical number there? What would be private bytes
and virtual allocation size for the devenv process?

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


IR> We're currently looking into options to alleviate this issue. It's
IR> becoming a more and more significant drain on productivity. At a
IR> rough guesstimate, we figure that we're losing about 20%
IR> productivity because of OutOfMemory exceptions related to RS:
IR> shutting down VS, restarting it, reloading the so
IR>
IR> lution, having RS load all its data into the various caches,
IR> grabbing a smoke or a drink in the mean time, and then getting back
IR> to work. And it seems like the more tooling we use (unit testing,
IR> stack traces, find results, fund symbols, navigation aids, etc.),
IR> the more often it happens.
IR>
IR> *Truth be told, the out of memory issue is more critical to us than
IR> all the other issues put together. It's more critical than bugs that
IR> crash VS and even bugs that delete our code (we've got source
IR> control!), never mind new quick fixes and contextual options and
IR> support for new language constructs and whatnot.* RS obviously isn't
IR> the only productivity drain, but it is significant. So much so that
IR> some of our programmers are disabling RS on their machine by default
IR> and then enabling the add-in only occassionally, for specific
IR> purposes, or even ditching it altogether. New programmers that join
IR> the team really want RS when they see what it can do, but only after
IR> it "starts working right".
IR>
IR> So we're looking into various options for reducing the memory
IR> footprint and overcoming this hurdle, so we can work more
IR> productively with RS. Were looking
IR>
IR> 1. Do you have any metrics for what constitutes a healthy "project
IR> size", should we choose to split up our large solutions?
IR>
IR> 2. Is it the number of code constructs (classes, interfaces, enums,
IR> etc.), lines of code, number of files, file size or some other
IR> measure that most affects RS?
IR>
IR> 3. Is the issue affected more by the number of projects or by their
IR> size?
IR>
IR> 4. If we were to hypothetically split the solution up into 2
IR> solutions and open each in a separate VS side-by-side on a duo or
IR> quad machine, would that help (since each would reside at runtime in
IR> its own 2GB address space)?
IR>
IR> Do you have any ideas, tools or recommendations for reducing the
IR> memory footprint, in the mean time? Any case studies, by any chance,
IR> or solid metrics you can publish?
IR>
IR> Thanks!
IR>
IR> ---
IR> Original message URL:
IR> http://www.jetbrains.net/devnet/message/5233093#5233093


0

Please sign in to leave a comment.