At 03:42 PM 6/21/2005, you wrote:
My questions: On one of Combee's articles he says: "Records read with
DmGetResource and DmGetRecord will stay in the cache until released by the
appropriate DmReleaseResource/DmReleaseRecord call. In the current
implementations, resources will stay in the cache until the resource DB is
closed, but data records can be purged if space is needed."
Um...How is this purge done? (I've missed that somehow.) Is it slow or
fast?...
The purge is done when the system tries to open a record that won't fit
into the available space. The system discards records that aren't in
use. However, it's detection of "not in use" sometimes isn't very accurate.
I *do* keep my 6MB database open, though I rarely do more than
DmGetResource/Copy/DmReleaseResource one resource at a time. Is the right
solution to simply "purge" between each resource access? Or to check the
size each time and purge when available space is below a certain
threshold? (What is more efficient/speedier, as this loop needs to remain
rather fast?)
You shouldn't try to micromanage this yourself. It's very hard to tell
what's going on. It should "just work", but on 5.4.5, it often
doesn't. That's less of a problem on 5.4.7 and 5.4.8.
I assume this means treating the internal volume as a VFS volume and using
the same techniques I currently use to read from the resource database
when stored on expansion?)
That's right. The format on the internal volume isn't PRC/PDB, but a
format with its own allocation table designed for efficient updating of
records. It also changes from OS version to OS version.
My resource database is indeed larger than the DBCache of NVFS. But I do
not access all of the data there, and relatively little at a given time.
It is accessed, copied, then closed. So does the NVFS caching scheme still
work okay, if I can just add a little purging? Or is it superior to bypass
the DBCache and treat the internal file scheme as VFS instead? Am I
misunderstanding either of these options or are there other potential
pitfalls with either?
Using the internal file system is really only recommended for databases
that you need to store in internal memory using your own format. For
example, the Photos app uses it to store JPGs on the Treo 650, avoiding
Palm OS database overhead.
-- Ben Combee, Senior Software Engineer, palmOne, Inc.
"Combee on Palm OS" weblog: http://palmos.combee.net/
Developer Forum Archives: http://news.palmos.com/read/all_forums/
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
