0

Timing pain

PocketPC 2002 is not a speed demon. PocketPC 2002 with .NET Compact Framework is even less speedy. PocketPC 2002 with .NET Compact Framework and a lousy data access strategy downright sucks.

It’s not the actual operation of the code, it’s the data loading at startup that takes forever. Apparently there are some limitations in the .NET CF that stand out really obvious while doing some kind of XML processing. I’m using XML because that’s how the sessions, speakers, rooms data is distributed and stored. But the lack of XPath functionality in the .NET CF is a killer if you want to use XML as a memory storage system, so you have to convert it to something more manageable (Hashtables, in my case).

I did some “timed runs” of PDC Sessions running on my device (Toshiba e740), and the results ranged from disappointing to embarassing. I say results because I’ve tried several methods of accessing the XML data files, so let’s see a couple of results.

XML DOM (create an XmlTextReader, create an XmlDocument, use the XmlDocument.Load method and then do a foreach on the ChildNodes):

Apparent start 00s
Before XmlDocument.Load 01s
After XmlDocument.Load 21s
Usable UI 29s

Ouch. Well, I tried using a DataSet and a Schema created out of the XML Data and calling a DataSet.ReadXML method: 37s. Not good. Apparently reflection on the .NET CF is not a good thing to use… and both DOM and DataSets use reflection a lot. I know that Windows Mobile 2003 is much faster in this (3x) and supposedly the .NET CF v.Next will further improve (2x?) but I’m stuck with my UNUPGRADEABLE Toshiba, so I’ll have to make do with it.

Then I tried doing it the SAX way. Create a XmlTextReader, zip thru it forward-only and build our structures on the fly.

XmlTextReader r = new XmlTextReader(fileName);

while (r.Read()) {
}

Ran this code, it took 10s. Hrm. It should have been faster (we were not really doing anything) but it was a definite improvement. Then I added a switch statement in the loop to figure out what NodeType we were reading. Ran again. 18s. Note that the switch again wasn’t doing anything, just testing for a bunch of NodeTypes. This wasn’t looking well.

Luckily I was not alone in my efforts. Both Joshua Allen and Woody Pewitt were assisting me via the magic of IM. (suggestion to the Whidbey team: put IM, whiteboard and shared documents functionality directly in the IDE. I use it maximized and it’s a pain to switch back and forth everytime my taskbar buttons flash)

Woody worked very hard to provide me with sample code and a coherent way to try to solve my performance problem. In the end, we decided to drop native XML processing and go towards a two step solution:

  1. load the XML into a database,
  2. use the database, Luke!

The database choice was kinda of obvious, and so SQL Server 2000 CE Edition found its way on my device. Now, loading the full XML datafile into the database takes about 50s, but it’s something you’ll do only when there are updates available. Startup time of the application has been cut down to 7s or so. If you’re lucky to have a Windows Mobile 2003 device, I suspect the startup time could even be negative or something…

Leave a Reply

Your email address will not be published. Required fields are marked *