Memory usage Update ( 2.5.1 )

I haven't switched over to the EAP 2.5.2 update, but I just wanted to share
with folks like Valentin,
what I experiences with 2.5.1 after I tried using the performance monitor
with his suggestion to watch the .NET CLR heap with and
without R#.

Interestingly enough, I turned off R# via the registry, and loaded my
solution into VS2005, ok.
It's big, the devenv VM size is roughly 164Mb. pretty big, but hey, it's a
big project.
I even switched between build (Debug Instrumentation -> Debug No
Instrumenation )configurations just to see if there was any big difference,
and there wasn't
maybe a 1-2 MB here or there. The big change happened when I went to:

Tools->Add-ins...and selected to turn R# back on........3 guesses what
happened.
IF this was April fools days still, I would've said "Nothing !", but sadly
no....the fact is that the VM size grew to
TWICE what it was before. To about 334Mb.

I then switched back and forth ( Debug No Instru -> Debug Instru -> Debug No
Instru ).
On the first switch, the VM size grew a bit, and then somewhere the GC
must've woken up,
because it brought down the size of the VM back down to 258Mb where it sits
now.

Anyway you slice it, there's approximately 100Mb, yes, 100Mb of ram to
support R# within my solution,
which is just shy of 2/3's of what the whole solution itself took to begin
with.

I already have to turn off code analysis on files that are bigger then a
couple of K lines. For all I enjoy about R#, I can't think that anyone would
say that 62.5% extra memory is acceptable. True, it is a big solution, but
that's only because there are about 40+ screens, a little more than a dozen
dialogs, plus BI and instrumentation code ( which in some instances was
excluded because of configuration switches ).

So maybe I should try this same experiment on a teeny tiny solution, with
one form, and see happens then. Perhaps there's some pattern to your memory
usage. Some point beyond where the necessity of the in memory database ( I'm
presuming you're keeping some sort of in-memory database of object refs,
word indices, etc. )
goes a little asymptotic. Either way, whatever VS's issues might be .NET
heap wise, there are definitely some issues involving R# that could use a
look see.

Sorry to have been so long winded, but I just figured I'd share what I'd
come across.

Marcelo


9 comments
Comment actions Permalink

Update on my own update:

Some other trivia about this test run:

1. VS2005 w/o R# active as addin, simple startup ( No Solution loaded ) -
45Mb
2. Load .NET CF solution ( only 1 screen with 8
- 101Mb
3 .Activate R# within Debug ( Default )
- 115Mb

It takes 14Mb to store information about 1 screen ( plus one ancillary,
non-UI object class ) and references to:

mscorlib,System, System.Data, System.Drawing, System.Windows.Forms,
System.Xml

from the .NET CF ?

This is a little toy project, I'm planning on putting out as Open Source,
rewritten from some java code which was originally put out
as open source, plus a UI to make it useful to run on a Windows Mobile unit
( like my phone ). So once I'm done, and it's
ready to be posted out on SourceForge ( or somewhere along the lines of
that ), I could provide the whole project for someone
to use as a test bench.

Also, for reference:

4. Start up VS2005 just like #1 above - 45Mb
5. VS2005 w/o R#, having just done (File->New Project->Windows Application,
and let it put up the blank form ) - 78 Mb( then coalesces to 73Mb )
6. Activate R# just like #3 above - 115Mb ( this, really surprised me ** ).

Now about **, I can sort of see that, if R# pre-allocates certain amount of
memory by default every time it comes up, it can gain a little boost by not
having to dynamically allocate too often on-the-fly. That seems pretty
logical, so I can't argue against that.

However, that makes me wonder if similar logic is applied across the board,
and that's the case, perhaps the question becomes...

Does the bigger your project, will R# that much more pre-allocate extra
memory with that extra padding ( I hope it's a not a 2x's allocation ) from
the heap to save itself from having to allocate as often. ?

Anyway, my apologies again for rambling. Hope someone finds all this banter
useful.

Marcelo



"Marcelo Lopez" <marcelol240@yahoo.com> wrote in message
news:euresq$aqo$1@is.intellij.net...
>I haven't switched over to the EAP 2.5.2 update, but I just wanted to share
>with folks like Valentin,

what I experiences with 2.5.1 after I tried using the performance monitor
with his suggestion to watch the .NET CLR heap with and
without R#.

>

Interestingly enough, I turned off R# via the registry, and loaded my
solution into VS2005, ok.
It's big, the devenv VM size is roughly 164Mb. pretty big, but hey, it's a
big project.
I even switched between build (Debug Instrumentation -> Debug No
Instrumenation )configurations just to see if there was any big
difference, and there wasn't
maybe a 1-2 MB here or there. The big change happened when I went to:

>

Tools->Add-ins...and selected to turn R# back on........3 guesses what
happened.
IF this was April fools days still, I would've said "Nothing !", but sadly
no....the fact is that the VM size grew to
TWICE what it was before. To about 334Mb.

>

I then switched back and forth ( Debug No Instru -> Debug Instru -> Debug
No Instru ).
On the first switch, the VM size grew a bit, and then somewhere the GC
must've woken up,
because it brought down the size of the VM back down to 258Mb where it
sits now.

>

Anyway you slice it, there's approximately 100Mb, yes, 100Mb of ram to
support R# within my solution,
which is just shy of 2/3's of what the whole solution itself took to begin
with.

>

I already have to turn off code analysis on files that are bigger then a
couple of K lines. For all I enjoy about R#, I can't think that anyone
would say that 62.5% extra memory is acceptable. True, it is a big
solution, but that's only because there are about 40+ screens, a little
more than a dozen dialogs, plus BI and instrumentation code ( which in
some instances was excluded because of configuration switches ).

>

So maybe I should try this same experiment on a teeny tiny solution, with
one form, and see happens then. Perhaps there's some pattern to your
memory usage. Some point beyond where the necessity of the in memory
database ( I'm presuming you're keeping some sort of in-memory database of
object refs, word indices, etc. )
goes a little asymptotic. Either way, whatever VS's issues might be .NET
heap wise, there are definitely some issues involving R# that could use a
look see.

>

Sorry to have been so long winded, but I just figured I'd share what I'd
come across.

>

Marcelo



0
Comment actions Permalink

Thank you very much for your investigations.
I have a few comments:

1) While up-to-date developer computer has 2+ Gb of RAM, extra 100M usage
doesn't matter
2) VS itself has it's own code model for intellisence, rafactorings, "Goto
Definition" feature, and so on. At ReSharper, we can't use VS native data
structures, and have to collect and store all this information by ourselves.
So, the memory usage is doubled, and one half isn't used almost at all.
3) For ReSharper 3.0, we've optimized memory requirements approx by 25%
(Mainly, by not loading LOH)

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Marcelo Lopez" <marcelol240@yahoo.com> wrote in message
news:euresq$aqo$1@is.intellij.net...
>I haven't switched over to the EAP 2.5.2 update, but I just wanted to share
>with folks like Valentin,

what I experiences with 2.5.1 after I tried using the performance monitor
with his suggestion to watch the .NET CLR heap with and
without R#.

>

Interestingly enough, I turned off R# via the registry, and loaded my
solution into VS2005, ok.
It's big, the devenv VM size is roughly 164Mb. pretty big, but hey, it's a
big project.
I even switched between build (Debug Instrumentation -> Debug No
Instrumenation )configurations just to see if there was any big
difference, and there wasn't
maybe a 1-2 MB here or there. The big change happened when I went to:

>

Tools->Add-ins...and selected to turn R# back on........3 guesses what
happened.
IF this was April fools days still, I would've said "Nothing !", but sadly
no....the fact is that the VM size grew to
TWICE what it was before. To about 334Mb.

>

I then switched back and forth ( Debug No Instru -> Debug Instru -> Debug
No Instru ).
On the first switch, the VM size grew a bit, and then somewhere the GC
must've woken up,
because it brought down the size of the VM back down to 258Mb where it
sits now.

>

Anyway you slice it, there's approximately 100Mb, yes, 100Mb of ram to
support R# within my solution,
which is just shy of 2/3's of what the whole solution itself took to begin
with.

>

I already have to turn off code analysis on files that are bigger then a
couple of K lines. For all I enjoy about R#, I can't think that anyone
would say that 62.5% extra memory is acceptable. True, it is a big
solution, but that's only because there are about 40+ screens, a little
more than a dozen dialogs, plus BI and instrumentation code ( which in
some instances was excluded because of configuration switches ).

>

So maybe I should try this same experiment on a teeny tiny solution, with
one form, and see happens then. Perhaps there's some pattern to your
memory usage. Some point beyond where the necessity of the in memory
database ( I'm presuming you're keeping some sort of in-memory database of
object refs, word indices, etc. )
goes a little asymptotic. Either way, whatever VS's issues might be .NET
heap wise, there are definitely some issues involving R# that could use a
look see.

>

Sorry to have been so long winded, but I just figured I'd share what I'd
come across.

>

Marcelo



0
Comment actions Permalink

Hello Marcelo,

Some comments below inline:

ML> It takes 14Mb to store information about 1 screen ( plus one
ML> ancillary, non-UI object class ) and references to:

That's what takes most memory:

ML> mscorlib,System, System.Data, System.Drawing, System.Windows.Forms,
ML> System.Xml

We have to have all symbol information at hands, because many feature of
ReSharper requires them instantly. In 3.0, as Eugene already noted, we optimized
it a lot. However, we will probably use this memory for something useful :)

ML> Now about **, I can sort of see that, if R# pre-allocates certain
ML> amount of memory by default every time it comes up, it can gain a
ML> little boost by not having to dynamically allocate too often
ML> on-the-fly. That seems pretty logical, so I can't argue against
ML> that.

No, ReSharper doesn't preallocate any memory until it needs. All that allocated
memory is full of information about your code, allowing ReSharper to respond
instantly to your actions.

Sincerely,
Ilya Ryzhenkov

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


0
Comment actions Permalink

My issue with memory occurs when Visual Studio says there is not enough
memory to complete some operation, and the task manager says I've got 1GB or
more of memory available for use. This always requires a restart which
easily takes me 10 minutes or more. With heavy use, it can happen several
times a day. I don't know how ReSharper figures into this puzzle, but it is
much more likely to happen when ReSharper is loaded.

Jeff

"Marcelo Lopez" <marcelol240@yahoo.com> wrote in message
news:euresq$aqo$1@is.intellij.net...
>I haven't switched over to the EAP 2.5.2 update, but I just wanted to share
>with folks like Valentin,

what I experiences with 2.5.1 after I tried using the performance monitor
with his suggestion to watch the .NET CLR heap with and
without R#.

>

Interestingly enough, I turned off R# via the registry, and loaded my
solution into VS2005, ok.
It's big, the devenv VM size is roughly 164Mb. pretty big, but hey, it's a
big project.
I even switched between build (Debug Instrumentation -> Debug No
Instrumenation )configurations just to see if there was any big
difference, and there wasn't
maybe a 1-2 MB here or there. The big change happened when I went to:

>

Tools->Add-ins...and selected to turn R# back on........3 guesses what
happened.
IF this was April fools days still, I would've said "Nothing !", but sadly
no....the fact is that the VM size grew to
TWICE what it was before. To about 334Mb.

>

I then switched back and forth ( Debug No Instru -> Debug Instru -> Debug
No Instru ).
On the first switch, the VM size grew a bit, and then somewhere the GC
must've woken up,
because it brought down the size of the VM back down to 258Mb where it
sits now.

>

Anyway you slice it, there's approximately 100Mb, yes, 100Mb of ram to
support R# within my solution,
which is just shy of 2/3's of what the whole solution itself took to begin
with.

>

I already have to turn off code analysis on files that are bigger then a
couple of K lines. For all I enjoy about R#, I can't think that anyone
would say that 62.5% extra memory is acceptable. True, it is a big
solution, but that's only because there are about 40+ screens, a little
more than a dozen dialogs, plus BI and instrumentation code ( which in
some instances was excluded because of configuration switches ).

>

So maybe I should try this same experiment on a teeny tiny solution, with
one form, and see happens then. Perhaps there's some pattern to your
memory usage. Some point beyond where the necessity of the in memory
database ( I'm presuming you're keeping some sort of in-memory database of
object refs, word indices, etc. )
goes a little asymptotic. Either way, whatever VS's issues might be .NET
heap wise, there are definitely some issues involving R# that could use a
look see.

>

Sorry to have been so long winded, but I just figured I'd share what I'd
come across.

>

Marcelo



0
Comment actions Permalink

I've now been running w/o R# for a week, and dear God do I miss it. But it's
almost as if I can't have anything else running besides VS2005 when I have
R# up. Frankly, I have to take issue with Eugene on this one. Certainly my
statements were assumptions on possible application design of the internals
of R#, having worked on a very "EARLY" version of something akin to
intellisense for the IBM Visual Age C compiler for IBM over a decade ago.
Accepting that you can't latch into VS's own intellisense mechanism ( Hmm,
that makes me think something, but more to that another time ), and you
require your own database to refer back to, why not drive it via queries,
and have some sort of caching mechanism for the most frequently used
namespaces. That way, there isn't such a large need to have so many things
pre-loaded into memory.

Now, as far as most "Development machines". What planet is that statement on
? Serious development was performed on Operating Systems before the word
"gigabyte" ever crossed anyone's lips. I applaud the efforts to reduce R#'s
memory footprint, and look forward to what 3.X has to offer, but frankly,
doubling the amount of ram necessary is simply unacceptable. There has to be
some tradeoff. And with as much gain in productivity as R# provides, and
little time to look up things, and such has to be weighed against system
constraints. If 2Gb RAM is what your "average developer" target is, then I
suggest you state it on the website for everyone to see. I suspect that in
not too short a time period sales might indicate that that's an unrealistic
expectation. Not trying to be harsh, just inject a little bit commercial
reality into the equation.

Marcelo

"Jeff" <jeffwalsh@hotmail.com> wrote in message
news:euuaqi$t2s$1@is.intellij.net...

My issue with memory occurs when Visual Studio says there is not enough
memory to complete some operation, and the task manager says I've got 1GB
or more of memory available for use. This always requires a restart which
easily takes me 10 minutes or more. With heavy use, it can happen several
times a day. I don't know how ReSharper figures into this puzzle, but it
is much more likely to happen when ReSharper is loaded.

>

Jeff

>

"Marcelo Lopez" <marcelol240@yahoo.com> wrote in message
news:euresq$aqo$1@is.intellij.net...

>>I haven't switched over to the EAP 2.5.2 update, but I just wanted to
>>share with folks like Valentin,
>> what I experiences with 2.5.1 after I tried using the performance monitor
>> with his suggestion to watch the .NET CLR heap with and
>> without R#.
>>
>> Interestingly enough, I turned off R# via the registry, and loaded my
>> solution into VS2005, ok.
>> It's big, the devenv VM size is roughly 164Mb. pretty big, but hey, it's
>> a big project.
>> I even switched between build (Debug Instrumentation -> Debug No
>> Instrumenation )configurations just to see if there was any big
>> difference, and there wasn't
>> maybe a 1-2 MB here or there. The big change happened when I went to:
>>
>> Tools->Add-ins...and selected to turn R# back on........3 guesses what
>> happened.
>> IF this was April fools days still, I would've said "Nothing !", but
>> sadly no....the fact is that the VM size grew to
>> TWICE what it was before. To about 334Mb.
>>
>> I then switched back and forth ( Debug No Instru -> Debug Instru -> Debug
>> No Instru ).
>> On the first switch, the VM size grew a bit, and then somewhere the GC
>> must've woken up,
>> because it brought down the size of the VM back down to 258Mb where it
>> sits now.
>>
>> Anyway you slice it, there's approximately 100Mb, yes, 100Mb of ram to
>> support R# within my solution,
>> which is just shy of 2/3's of what the whole solution itself took to
>> begin with.
>>
>> I already have to turn off code analysis on files that are bigger then a
>> couple of K lines. For all I enjoy about R#, I can't think that anyone
>> would say that 62.5% extra memory is acceptable. True, it is a big
>> solution, but that's only because there are about 40+ screens, a little
>> more than a dozen dialogs, plus BI and instrumentation code ( which in
>> some instances was excluded because of configuration switches ).
>>
>> So maybe I should try this same experiment on a teeny tiny solution, with
>> one form, and see happens then. Perhaps there's some pattern to your
>> memory usage. Some point beyond where the necessity of the in memory
>> database ( I'm presuming you're keeping some sort of in-memory database
>> of object refs, word indices, etc. )
>> goes a little asymptotic. Either way, whatever VS's issues might be .NET
>> heap wise, there are definitely some issues involving R# that could use a
>> look see.
>>
>> Sorry to have been so long winded, but I just figured I'd share what I'd
>> come across.
>>
>> Marcelo
>>
>



0
Comment actions Permalink

I've been watching this thread for a while now to see where things would end up and I feel compelled to reply now, particularly in response to Marcelo's text:

"If 2Gb RAM is what your "average developer" target is, then I
suggest you state it on the website for everyone to see."

Frankly, I WISH R# could even use 2Gb of RAM. Sadly, R# starts to cough up exceptions left right and centre and basically stops working as soon as devenv takes up much more than 700mb of RAM or so. I love R# and plan to keep on using it as long as I can, but if memory usage for a given solution continues to increase (due to added features) without increasing the total amount of memory that R#/devenv can use before R# falls over, I can quickly imagine a time when R# won't work at all for large solutions, let alone run for a while and then need a restart. :(

Jeremy

0
Comment actions Permalink

In response to Eugine's comment: "While up-to-date developer computer has 2+ Gb of RAM, extra 100M usage
doesn't matter"

Whilst I am in a lucky position to agree that development with 2+ Gb of RAM makes life a lot easier, I think this is a fairly flippant remark that may get you a whole lot of angrly replies.

The reality is that many companies' IT departments still see 1GB as a lot of memory. In my industry, developers regularly get the short straw where memory is concerned.

I suggest that 100M extra usage DOES matter to a lot of people.

I do agree with Marcelo. If you are inferring that there is a high minimum RAM footprint for R#, then say so on your product page.

0
Comment actions Permalink

"Frankly, I WISH R# could even use 2Gb of RAM. Sadly, R# starts to cough up exceptions left right and centre and basically stops working as soon as devenv takes up much more than 700mb of RAM..."

I agree with this 100%, R# dies whenever a project gets big.

0
Comment actions Permalink

Wow, I wasn't expecting to strike a chord like this. But apparently I've hit
a nerve with some people. Thanks to those who agree. Hopefully someone from
JetBrains will respond, or at least do take some more serious consideration
of these issues. If no one has stated their opinion on this in the "Please,
STOP adding new features" thread, you might want to have a look, as there
are some folks there who're also in agreement with what we seem to be in
agreement about, but have approached it in a "democratic" way ( i.e. casting
votes, or mock votes as the case may be ).



"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:23175081.1176311520715.JavaMail.itn@is.intellij.net...

I've been watching this thread for a while now to see where things would
end up and I feel compelled to reply now, particularly in response to
Marcelo's text:

>

"If 2Gb RAM is what your "average developer" target is, then I
suggest you state it on the website for everyone to see."

>

Frankly, I WISH R# could even use 2Gb of RAM. Sadly, R# starts to
cough up exceptions left right and centre and basically stops working as
soon as devenv takes up much more than 700mb of RAM or so. I love R# and
plan to keep on using it as long as I can, but if memory usage for a given
solution continues to increase (due to added features) without increasing
the total amount of memory that R#/devenv can use before R# falls over, I
can quickly imagine a time when R# won't work at all for large solutions,
let alone run for a while and then need a restart. :(

>

Jeremy



0

Please sign in to leave a comment.