One of the reasons given in the documentation as to why I'd want to use
feature memory as opposed to a database record is that feature memory
access is much higher performance, because there's no finding / opening
/ getting / locking // unlocking /releasing / and closing. You just USE
it. And since it's a nonmoveable chunck, you can even save the pointer
and don't need to do additional FtrGets, although you do need to watch
for soft resets...
Let's say I keep a database open, so now the database overhead is, say,
this:
hRecord = DmGetRecordIndex(pDB, i);
pData = MemHandleLock(hRecord);
...
MemHandleUnlock(hRecord);
DmReleaseRecord(pDB, i, true);
Can anyone give me a sense of just how much is going on behind the
scenes from a performance perspective or how quickly they execute from a
user perspective? Are system traps (interrupts, supervisor mode)
involved? Memory traversals? Memory protection? Elaborate validity
checks and comparisons? Or is it just a simple pointer dereference and
AND mask?
(I imagine something like this is all that's happening, but validation
could be extensive...)
// How is pDB verified as valid?
if (i < pDB->numRecords) hRecord = pDB->index[i].LocalID;
if (!LocalID->bLocked) // verifying LocalID and getting a struct could
get extensive
{
LocalID->bLocked = true;
return LocalID & (pDB->CardNo << 24);
}
etc...
Much appreciated!
- Jeff
(We won't mention the incentive feature chunk can be slightly less than
4 gigabytes in size, although right now its limited by the 256 Meg card
limit. I wonder why something with restricted use like features went
32-bit before the storage heap - rationale?)
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
