WeSay Development Progress

One of the things that’s been bugging us for the past couple weeks has been performance. Sure it’s fast on our machines but what about our target machine. There is quite a difference there. So I was finally able to get a Linux distribution (Ubuntu 6.06) on an old Dell Latitude CP M233XT (Pentium II 233 128MB Ram). While the amount of ram is the same as our target machine, the clock of the Dell is much slower than the OLPC’s. When I ran WeSay, it was very responsive. It did take around 12 seconds to launch but once it was up, moving around was pretty much instantaneous with a slight hint of a lag occassionally. Needless to say, we are very pleased. The mono+WeSay footprint was around 48M. The system was using 20M of swap.

These have been an exciting last few days, as our prototype has got to the place where we can start getting some questions answered. Happily, our quick tests (just looking at the Windows Task Manager), show that we can load the prototype with a 32k-word Thai glossary in just a couple seconds on my laptop, using only 22 Megs of RAM. A test with only 5k words took just a meg or so less. So we effectively don’t have to care how big the user’s dictionary gets. Even scrolling through the list (which is very fast), the RAM usage doesn’t grow more than one meg, and then it drops back. Score one for db4o & Eric’s lazy TreeView. This doesn’t count the RAM used by the .net framework itself, though. On a mono install, we’ll have some overhead that we haven’t measured yet.

Our prototype is finally starting to shape up. I spent the past few days figuring out how to do lazy loading into a GTK TreeView. Normally, you would pass all the data to the TreeStore which would then be the container that the TreeView would display but we wanted the data to stay in the database unless we asked for it. (The idea being that we might need to support a database of 30,000 entries and don’t want it to have to consume the memory that all of those would require.) What we wanted was a class that implemented TreeModel (so the TreeView would display it) but that either got it’s data directly from our database or used an adapter over our database but in any case did not actually store the data itself.

I started out by trying to implement the TreeModel interface but after a failed attempt there (the GTK# bindings don’t let you just implement the interface, you have to do C magic!). I decided to use the NodeStore and NodeView way of handling this as it was much more friendly to GTK#. I ended up writing a specialized class (TreeModelAdapter) in the fashion of NodeStore. The downside, is I also have to end up writing my own NodeView class since NodeView is bound directly to NodeStore and not to an interface.
What I really want was something like NodeStore but that used an interface to a store (IList maybe) instead. Sometime later when we aren’t in prototype mode, I’ll see about sitting this over an IList or other appropriate interface.

At the end of the day, John and I worked on figuring out how to handle configuring the app. And a discussion on adding entries and filtering summarized here.