WeSay Development Progress

After two discouraging days of trying to get Mono to work on the OLPC image, I have finally figured out why I was up against such a brick wall. The first problem I had was that the Mono installer for linux only provides bindings for GTK+2.4 and we have been using GTK+2.8. After unsuccessfully trying to use a machine.config file to tell mono that it can use GTK+2.4 in place of 2.8 (which I don’t know that it would have worked but I couldn’t get it to recognize that even), I finally decided to just copy over the 2.8 bindings from my ubuntu install.

Now I thought it would be easy from that but after awhile of getting all that hooked up, I determined that the gtk version on the OLPC must not be old enough and I copied over the ubuntu libs, only to find when I was going to copy them that the OLPC distribution is using GTK+2.10.

Apparently Fedora has a version of Mono that will work with GTK+2.10, so I have now decided I’m either going to have to build my own image Mono as a part of it or wait until Mono supports GTK+2.10.
On a whim, I took up Daniel Olivera’s offer to access his OLPC motherboard and ran some performance benchmarks to see how this compares to our test machine. The benchmarks seem to indicate that our test machine is about 75% as fast as the OLPC. You can read more details about it here. This puts my previous blog about the performance of WeSay on our test machine into better perspective.

Further testing on the memory usage seems to indicate the WeSay+Mono footprint on Linux is not 49MB as we previously thought but 19MB which is more like what we had found on Windows as well.

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.