Hydra - Memory Wars

Well, these first few weeks since I made Hydra public pretty much have shown me the way Hydra should develop in the future. First and foremost - reducing the memory footprint. I am running a battery of tests (using memory profiler found at http://memprofiler.com/) to discover where all this memory goes, and for now discovered two important things:
1. there's not much I can really do about it, as Garbage Collector really does its work rather well and doesn't allow messing around much;
2. I can achieve some effect by regularly reducing application's working set and thus swapping memory - in fact, that's exactly what Hydra already does when minimized, and achieves great results in doing so (reducing memory consumption from 120 MB to 16MB, or 6-7 times...).
I'm not entirely happy with both statements, and I'm really frustrated with the current state, so in the next couple of weeks I am going to battle and hopefully will reach some acceptable level of memory consumption. I'm aware there are a lot of improvements I can make in code itself (especially regarding string handling, where I have the option to use string builder more often, instead of allocating strings directly, but I somehow doubt it'll add some significant improvements over the current state of things). I'll also try to document my findings here, since it might be of some use to my fellow programers. In order to track progress, let's document the situation as it is, before any of the optimizations took place.




This is the image taken immediately after Hydra is started, picture speaks for itself... Hydra's working set occupies 54 MB of RAM.



Here is another screenshot - this time there are two open tabs. Performance penalty is drastic, as each loaded tab adds incredible 25 MB load on application! Microsoft warns about the webbrowser control as insatient memory eater, but this is way to much...



And now the incredible change, as Hydra is minimized, the working set gets freed up - the result is amazing - from 102 MB to 7 MB in a second! Of course, this is rather elusive, as the application will request this memory back again once it gets reactivated.
Much more important information about the memory consumption can be obtained from the PerfMon tool that can be run from the Run command (Start->Run>>Perfmon>>OK). In order to track a process using Perfmon, right click the counters list and choose 'Properties'. Click on 'Add' button, and then under 'Performance object' select 'Process' instead of 'Processor'. In the list of active processes choose the process you wish to track. In the 'Counters' section choose 'Working Set' and 'Private Bytes' counters and add them to active counters. In my case, I decided to track Hydra, Firefox and Internet Explorer (you'll notice that IE has significantly larger values than Hydra and Firefox, in its defence I can just say that its session was quite long, and it's rather natural for an app to accumulate more memory usage when it runs longer).



Here you see the results - Hydra is losing when compared to Firefox, while it has an advantage relating to IE. In fact, Hydra would take about 5-10% more memory than IE under the same circumstances.
Well, this concludes part one of this great saga, I'll update you on the progress as it goes :-)