I'm not convinced that this is a memory leak - I haven't seen the process actually running out of memory (VMMap sysinternals). Two other possibilities are -
- a problem with the code attempting to erroneously allocate a ridiculously large amount of memory - it's not the first time it's happened, especially if multiple threads are accessing a shared object and the object isn't locking access to a single thread at a time (A and B try to access C - while A is using it, B comes in and messes up the data)
- memory fragmentation is another possibility
Nothing a user can do about it, however. Elliot has to track it down and fix it.
But imo, DW probably needs a custom memory pool to get around the 2G limit in .Net - but that's just a guess, as I can only guess at how Elliot is handling his memory. There is no real reason why DW should be limited to 2G memory limit imposed by .Net.
A 64-bit version would also be nice, as it's becoming more and more common these days. I have no idea how hard this would be to do with C#. Perhaps food for thought for the next version of DW.
Looks like it would be more trouble than it's worth to recompile for 64-bit at this point. If the next version of DW is going to require a major rewrite, it might be worth considering, however.
< Message edited by Kayoz -- 5/25/2012 4:58:52 AM >
“That which can be asserted without evidence, can be dismissed without evidence.” ― Christopher Hitchens