Due to popular demand, I will presently describe what we have come up with
investigating OutOfMemory issue (RSRP-18766) that plagues ReSharper since
As it happens, there can be three different circumstances under which System.OutOfMemory
may be thrown:
1) "True OutOfMemory": ReSharper demands the amount of memory that is greater
that physically available on system (RAM+Pagefile). We believe that on a
reasonable box this never happens in ReSharper 2.5.2. We sometimes eat lots
of memory, but essentialy if you can open your solution in plain VS on given
box without trashing, you shouid be able to do so in VS+ReSharper, although
for small RAMs you will trash a lot. We do work on reducing our memory footprint,
but of course ReSharper features come at a price. You cant expect us to do
more that VS in the same amount of memory. Anyway, I am not aware of ReSharper
encountering 'true OutOfMemory' on any projects.
2) "hResult= E_OUTOFMEMORY". Many COM calls indicate some generic errors
by returning hresult E_OUTOFMEMORY. .NET COM Interop chooses to communicate
this fact to the managed code by throwing OutOfMemory exception.
ReSharper uses Visual Studio COM classes heavily, and, as you may have guessed,
the conditions under which various COM calls fail with E_OUTOFMEMORY are,
to say the least, somewhat underdocumented. What we do in that case is try
to figure out these conditions, not call the offending methods in these cases,
and, as the last resort, just put these call under try/catch(OutOfMemory)
and fail gracefully.
As you may understand, this is an ongoing battle, and we will try to fix
all these calls in 3.0.
3) Large Object Heap troubles. See: http://www.codeproject.com/csharp/Large_Objects____Trouble.asp
Apperently 32bit XP version of .NET 2.0 may fail to allocate big arrays in
some conditions when there are plenty of memory. Worse, Large Obejct Heap
becomes corrupted in that case, and subsequent memory allocation requests
may randomly fail with OutOfMemory exception. ReSharper currently sometimes
tries to allocate big arrays, and we are currenly in the process of replacing
these big arrays with fragmented arrays. I am afraid we will not be able
to backport all of these fixes to 2.5, although we will try to backport the
most critical ones.
These are results of our investigations for RSRP-18766 so far.
Addressing OutOfMemory issues one of our priorities for ReSharper 3.0 release,
and, I believe, we have by now identified the main causes for them and we
hope to fix all of those in 3.0 release.
I do not think there is much need to fly anyone anywhere yet :)
Hope this helps,
Technical Lead/Software Architect
"Develop With Pleasure!"