At 1:58 PM -0800 3/3/99, Mike Pellegrino wrote:
>Thanks for the reply. I have read that paper before a few times (as one
>may need to in this situation).
Really -- the new version? It's only been there for a month or so. Maybe
you're thinking of the older one.
>It does address performance issues on
>accessing records, but not in the creation, deletion, or writing of
>records which is what I was looking for. My instinct tells me that
>there is marginal difference between the two.
That's a good point. I'll make a note of it for the next revision.
>I cache the handles returned from DmNewRecord so that I don't ever have
>to call DmQueryRecord again while I interact with the paged area. So,
>when I need to access memory, I just lock record handles. This works
>very well, is fast, and I haven't found anything telling me it's bad
>practice, so I am running with it.
That's a fine way to do it. The only drawback is you have to keep track of
all the handles, but you're on top of that. One 2.0 devices with multiple
heaps, it's possible that heap compaction and balancing could move a
record, which would invalidate your handle. This should never happen on a
3.0 device. (Desktop synchronization can change handles too, but only if
it's replacing a record, which probably won't happen here.)
On the other hand, DmGetRecord takes an index and gives you the handle.
It's just an array lookup, so it's relatively fast. Also, indexes are
smaller objects than handles (2 bytes vs 4), so it might be safer to cache
the indexes instead of the handles. The indexes will remain valid until
you insert a new record at a lower index...
--Bob
