Yesterday I just squashed the « bug » which was causing DBus Explorer to be so slow. Alp had said that it was probably something simple and indeed it was. But first a little background : D-Bus Explorer’s first development took place when I was at school and thus without direct access to Internet. At that time the XML parsing was very quick though I used the worst possible way, XmlDocument + XPath, which was both resource hungry and overkill for a simple reading. Problems surfaced when I came back home with direct access to the net : suddenly and with no apparent reason D-Bus Explorer became very slow.

At first I suspected it was the way I was doing the XML parsing, as D-Bus explorer introspect (= parse XML data) recursively across D-Bus paths, thus loading ~5 different XML documents for a bus. So I ported the code to first use XPathDocument+XPathNavigator and then, as there were no improvements, to XmlTextReader which is the fastest way to read XML data. Still the problem was persisting.

So I decided to take the problem at the root and put Stopwatch at every possible place. It resulted that it was the first call to ReadToFollowing that was taking approximately 3 seconds. Then, because of the speed difference between here and at my school, I came to a realization : is this stupid parser trying to download the DTD file from Freedesktop each time I create a new XmlTextReader ? Turned out that it was exactly that. Each time I loaded a new XML document, XmlTextReader issued a WebRequest for the DTD (even though DTD validation was disabled) which is of course what slowed up everything. Setting the XmlResolver property of XmlTextReader to null solved the speed caveat and now the parsing of a normal service like Banshee is instantaneous (changement available in Git btw ).