MM2 is really slow compared with MM1, but it's doing the real time download and display, so we can't blame it too much. It's a challenging job and no GPS device can do it today. From the source code I go through, seems that there are still places to improve.

MM2 uses gdbm database to save the card space and make the interface simple, the drawback is that gdbm is not that efficient. Every time you fetch a key or data, it allocates memory twice - read from the file and make a copy then give it to you, user has to free the memory - this approach is not necessary in this application. I delete that in my windows gdbm library, since MS runtime simply refuses to free the memory and crashes. Redundant memory allocation of gdbm is a slow factor.

Hash value calculation is quite consuming in gdbm, which depends on the key length. The MM2 uses 12 byte key, it seems too long, there is no difficult to condense it to 8 byte length, it can save some time.

The most important, there is basically no cache management in gdbm, every time you fetch a key or data, it goes into reading file. It really slow you down. So implementing cache management is definitely a good way to smooth things up. From my point of view, it may be improved if we have a SW architecture like

GUI <--> cache management <--> downloading/file read/save

The three should be in separate threads.

GUI is to do map display and responding user input.

GUI talks to cache management, which should manage a pool of map tiles in ram, a few levels of surround area at least. Downloading and file reading should be transparent to it. It's up to the cache manager to decide where to get map files.

The download routine shouldn't save the downloaded map tiles right away as it does now, it should download map tiles into the memory and turn them over to cache manager. Cache manager decides when to save them - only at the time when GUI is idle and no user input, or cache pool is too big - which is unlikely since the device has 60m ram.

The best way to speed up the app is to avoid the three doing intensive jobs all together at the same time, so when GUI is busy the SW doesn't do saving, when downloading GUI should be told to wait, the central piece should be the cache manager.