Of course, the number of times you access a particular resource during one execution session is a critical factor. If it's many times per resource, then there's a clear performance advantage in importing the database into the storage heap once and reading it multiple times from there. But if you're only going to be needing a fraction of the resources in the .prc file, with a little extra work, you could read resources into the storage heap one at a time and cache them there, rather than releasing each one after use.
If your application doesn't need a particular resource more than once, the simplest and most memory-efficient approach would be to fetch each resource as needed via VFSFileDBGetResource and release it after use.
If this sort of mental analysis doesn't make it very clear which route you should go, it would cost very little extra work to code up both alternatives and try both. The differences could be encapsulated in three functions:
OpenFile: the alternative versions would, respectively, just call 1) VFSFileOpen, or 2) VFSImportDatabaseFromFile.
GetResource: 1) VFSFileDBGetResource 2) DmGet1Resource (or the like).
CloseFile: 1) VFSFileClose 2) DmDeleteDatabase.
As to finding the file you want in extended memory: Use VFSVolumeEnumerate to find all the extended memory cards on the device (typically 0 or 1), then use VFSDirEntryEnumerate, recursively if necessary, to find all the directories and files on each card. If you're in the position to specify the card layout (i.e., if you're not working with an already-defined directory layout), you should create conventions for the names of the directories in which the optional .prc files should reside. If there's always going to be just one .prc file per card, maybe you're fortunate enough to be able to specify the exact path name where it should be found, and not have to use VFSDirEntryEnumerate at all.
Greg Lutz NearSpace, Inc.
At 06:18 PM 2/15/2004, Ted Peters wrote:
Hi all,
an application that I am developing also has an optional PRC file with additional data in resources.
Currently I find this file with Dm functions, but obviously that doesn't work if it's not in main storage. I know the file's name, type, and creator code. I only need read access, but there is a fair amount of data (>500 KB), and I need access to it for the duration that my app is running.
What is the best strategy for working with this file if users place in on an expansion card?
How do I go about finding the file?
What's the best way to use it? Is it practical to use VFSFileDBGetResource() instead of DmGetResource() calls? Or should I import the file to main memory and use my existing code from there? What are the time/speed/memory considerations?
Or should I just tell users that this is not supported and they have to place the file in main memory?
Any wisdom or suggestions appreciated.
Thanks,
Ted Peters
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
