Results 1 to 1 of 1
  1.    #1  
    Understanding the Performance of the Tungsten T5
    Sunday, 17 October 2004 9:11 PM
    Earlier this month, PalmOne released their newest PDA, the Tungsten T5. This device is the first Palm OS device to be released that uses NAND flash for the storage heap. This is a pretty major change to the way the device operates, and while the APIs for accessing memory haven't changed, what goes on at a low level is quite a bit different.

    In a traditional Palm OS device, the storage heap was part of the main system RAM and was a write-protected region of memory. To read from the storage heap, you just directly accessed memory through a pointer, but writes to the heap used an API that validated that the write was OK, unprotected memory, did the write, and then protected memory again. Getting a record or a resource from a database was a pretty quick operation, since it just required a lookup and changing a lock status.

    On new devices that put the storage heap in NAND flash, you've got a two-level design. When not in use, the databases are stored in flash memory, but not memory that can be directly read by the processor. NAND flash can only be read a sector at a time. The devices have a smaller amount of memory that's setup as a cache for the storage heap. This is protected RAM, and when a DB is opened, some of its records are copied out of NAND flash into the storage heap cache. For really large databases, copying of some records may be delayed until they are accessed. Now, the program acts as normal, reading and writing records as if they were always in RAM. When the database is closed, any changes made to the cached copy are copied back to NAND flash, and the cache is released. This flushing of changes is also done during events like changing applications or hitting the power button. All this copying of data to and from NAND flash takes time. Even when no copying is done, there's a slight overhead involved in checking to see if the data is already in the cache.

    So, while a device may have a 64MB storage heap, it's actually able to get by with much less actual RAM; the device only needs RAM for the dynamic heap, the storage heap cache, feature memory, and for storing the parts of the OS that have to be accessible at all times.

    So, what does this mean for your program? For starters, if you modify records in a DB, be sure to use the DmGetRecord API, not DmQueryRecord. The query form tells the OS that you're not changing anything, and it may mean that changes you make aren't written back to NAND flash. Also, it may be a good idea to make separate index databases if you've got large DBs that you search. The index can be copied to memory quicker, and won't push items out of the cache as quickly. Finally, rather than opening and closing databases multiple times in your program, just open them once at the start, and close them when the program ends. This will avoid unnecessary flushing of cached data.

    In a sense, this new technology is really similar to the technique used by applications like PiDirect II back on the 68K versions of Palm OS. Not all Palm OS Garnet 5.4 devices will be using this; this is an optional feature that licensees can get from PalmSource. This feature is also implemented in Palm OS Cobalt 6.1, so devices that use that OS may have similar performance characteristics. In general, this is a good thing; it lets devices access more data without having to go to an external file system, it lets user data more easily persist when the device runs out of power, and it can improve the battery life of the device, as NAND flash doesn't have to be powered to retain its data. However, the implementation may cause some programs to run slower; already users are reporting that the global find operation on the Tungsten T5 is painful.
    Last edited by Gekko; 11/27/2004 at 04:01 PM.

Posting Permissions