Larry, >So if I'm going to combine my records as you suggest, would >it be best to continue to use PDBs, or should I use PRCs?
In general, I just use PDBs. But there are cases where just making the "records" resources in the application PRC itself makes sense. An install or beam becomes self-contained, and you always know the data matches the version of the app which is running. This is less appropriate when the data changes more often than the app -- as is generally the case. And I also think it is a poor idea when you have so much data, because NVFS caching works better with PDB than with PRC contents. >I understand Feature Memory may be quite fast. The application is read-only. You don't need to go there. First off, you'd need the data on the device to be able to populate the feature memory the first time the app is run after each soft reset. So you'd end up consuming twice the memory again, which in your case is pretty significant. Plus the time it takes to allocate and populate the feature memory. >So if I could allocate 7 megs contiguous of Feature memory, I could have >a real fast and compact solution. What do you think? As Logan explains, you are unlikely to get 7MB contigous, except perhaps right after a hard reset. However, just "packing" your data will already give you a surprisingly fast and compact solution. And especially when you have fixed length data which is read-only (as is your case), the implementation becomes *very* simple. With your longest "record" being 26 bytes, you can get up to 2500 per PDB phyiscal record. However, as Logan suggests, you may want to put only 2048 logical records per physical record. This makes the math even more efficient because you can change the logical record into physical placement without even doing a divide operation: UInt16 idx; UInt16 offset; idx = logical >> 12; offset = ( logical && 0xFFF ) * fixedLength; The above treats the least significant 12 bits as the "logical" index within a physical record, and the most significant 4 bits as the physical index of the associated PDB record. For example, the value 10000 is hex 0x2710 so the data is located at physical PDB record index 2 (ie the third record starting with index 0) and is the 0x710 or 1808th entry into that record. If you then multiply that by your logical record length, you get the offset into the PDB record where the data begins. Just make some wrapper routines to pass back a logical record's contents given the record indexes you are already using now (which are currently physical indexes into PDBs with discrete records). What I do is have them use static variables to keep track of the most recently requested physical index, and when the next request is for the same physical record, I re-use my existing pointer to a locked handle to that PDB record. When it wants a different PDB record, I unlock the previous handle and find the new one. At program termination I unlock any I still have allocated. With having 2K "logical" records per physical record, you will likely find this will already provide a significant improvement to access times compared to your current approach. And you'll have vastly better hot sync times, and save over 6MB of overhead while you are at it. Doug -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
