Ken,
VMMHandleNew only allocates pages in storage RAM and sets up some
entries in some lookup tables.
Ultimately, I almost always will still need to do a DmNewRecord which is
where the time killer is. It doesn't really matter whether it happens
in VMMHandleNew or VMMHandleLock, etc. You are correct in that I would
buy a performance benefit if the handle is never paged because the
record creation won't ever occur for it to matter in the timings. But,
as soon as the first page occurs, there's that hit to DmNewRecord.
One thing that makes this whole project rather tricky is that even
internal lookup tables and such can get very large and may need to be
paged. Imagine allocating 10,000 100 byte blocks (about a megabyte in
storage space)--that lookup table isn't in dynamic RAM because it would
be something like 80K in size. So, there is an upper bound on the
amount of cached data and structures to manage it because it needs to be
stored somewhere, traversed quickly, yet be unpredictably large to
handle the most general circumstances.
I have a list of efficiency measures on my todo list to which I'll add
your suggestion--I've held off making things "too" fast on them for now
for this big reason:
It's easy to make working code fast, but it's much more difficult to
make fast code work 8-)
Thanks for your input Ken.
Mike
> -----Original Message-----
> From: Kenneth Albanowski [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, March 02, 1999 2:02 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: More memory problems.....
>
> On Tue, 2 Mar 1999, Mike Pellegrino wrote:
>
> > Neil,
> >
> > I have "finished" a beta virtual memory manager for the Palm which
> pages
> > dynamic RAM to the disk. What this means is that you can allocate
> more
> > RAM that physically available (I page it to storage RAM), but you
> can
> > only lock down handles if there is enough dynamic RAM to hold what's
> in
> > the handle. It may help you in your memory problems as far as
> storage
> > size goes.
> >
> > The docs aren't written yet (been a busy week so far-although the
> params
> > are identical to the Palm API calls) and I've not done enough
> stochastic
> > testing of the manager yet. But I'm happy to entertain beta users
> if
> > you're interested.
> >
> > The performance of VMMHandleNew sucks--it takes about 25-30 ms per
> > allocation. This is tied almost directly to DmNewRecord
> performance.
> > I'm currently investigating ways to improve this or amortize the
> cost
> > over a number of VMM operations. Other operations take much less
> time.
>
> Are you allocating underlying blocks in both the heap and storage
> during
> VMMHandleNew, or is the new handle just going into storage (since it
> starts out unlocked)? It sounds to me like it would probably (barring
> information to the contrary) make more sense to start out with an
> unlocked
> allocation on the heap, paging it out to storage only when heap fills
> up.
> Heap would then act as a cache for as many of the blocks as reasonable
> &
> possible, locked or unlocked, instead of only holding locked blocks.
>
> It would be more work to do it that way, though. :-)
>
> --
> Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
>
>
