Well, the POSE profiler said DmReleaseRecord takes about 5,000 cycles and
DmGetResourceIndex takes about 4,000 cycles. But that's 3
times slower than I get from straight ticks timing - could all that slow down be due
to running the POSE profiler? Or the way
TimGetTicks works?
It seems the slowest thing is DmReleaseRecord's calling MemHandleSize, which is really
surprising, since I wouldn't have thought
MemHandleSize would be so mammoth. Look how much you instantly learn about the PalmOS
from a profile dump!
Well, in any case, I appreciate all your help and the bottom line is that record
access takes at least thousands of cycles vs none
for feature memory or dynamic chunks.
Randy Maxwell wrote:
> Jeff,
>
> POSE provides a REALLY good way to answer your question.
> Just prototype the 2 different variants and run a Profile session on each.
>
> Details (down to clock cycles) are captured about both application AND Palm
> OS code time used.
>
> We have used profiling to optimize implementations with good results.
> Then we viewed the profiling results on a MAC.
> POSE profiling gave us insights into better combinations of Palm OS APIs to
> use that are
> difficult to get using any other approaches I am aware of.
> This has allowed our applications to run pretty well on Palm OS 2.0 and up.
>
> Reading about POSE profiling/searching the POSE forum should help...
>
> I can't give you any info about Features performance as our apps do not use
> them.
>
> Regards,
> Randy Maxwell
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
