One of the biggest adoption blockers for R# in my opinion is that for the middle to large projects R# kills VS performance and it happens because of VS process memory exhaust.
For example, after loading solution I currently work on to VS 2013 status bar shows that R# consumes 500 Mb of RAM. After some activity it grows to 1 Gb very often. Unfortunately VS is still 32-bit process (and I would not hold my breath for 64-bit version soon) and even on 64-bit OS when VS process takes above 2 Gb of memory (may be closer to 2.5 Gb) VS gets really slow and what is worse – unstable!
R# gets really useful for big projects, which take a lot of VS memory by themselves. Now R# also needs more memory to handle those and as the result by the time you really need it – it is barely usable.
I wonder if R# team considered extraction of memory hungry portion of it to run out of VS process? This can be taken to different levels. As a minimum R# can start helper process (64-bit if environment allows) and use it to keep its data structures as in-memory cache, while most of its code still runs inside VS. At a maximum level it would be most of the R# running as a separate process and only have proxy code in VS process.
Obviously this move would make R# slower than it is now, but I honestly believe that substantial part of R# customers would trade for slower but less VS affecting version any moment! Additional benefit would be stability – R# crash or malfunction in a separate process has much less chances to disturb VS.
Ideally this out of proc mode should be optional or even automatic, so that out of proc data structures and components are used when memory pressure in VS process increases above predefined threshold.
Thank you for consideration!