Definition: Spelunking (spee-lunn-king), when a geek puts his nose where it doesn’t belong.
Some internal interest in my post prompted me to see whether my hypothesis about why RSSBandit is slow is correct. To test it out I downloaded the source for the release that I was using and commented out the code in the OnUpdatedFeed.
Interestingly this just breaks the automatic generation of the unread posts indicators on the tree view – if you select the note it does update. Also interesting was the fact that the event dispatch code itself is what does the marshalling across to another thread. If this was a stand-alone API you wouldn’t necessarily want to do it that way but because Dare’s RssBanditApplication is bound to the UI its not too much of a problem.
Anyway – here is the allocation graph at <root> - you can see that it has changed a bit. First off the worker thread code is on top of the graph which makes sense because that is what deals with the strings and XML. I don’t have a screen shot but the histogram of allocated types also has strings on top which is what I originally expected.
As I scroll along (here you’ll need to use your imagination, its late and screenshots take time) there are no real stand-point problems, memory usage is down and it certain performs better in the application - but remember, its not really magic because all I did was apply a tried an true optimisation technique.
The best way to make code run faster is to not run it at all!