Hi All..
I decided to do a little experimenting with image caching in plucker,
and have come up with some very surprising results.
Using a news .pdb file, I ran a few benchmark tests and although they
may be a little tainted, more testing with other files should prove
consistent.
Here are some numbers (in ticks, according to debug.c's output):
Cache Enabled Cache Disabled
First Load Next Load First Load Next Load
Location Start Finish Start Finish Start Finish Start Finish
-------------------------------------------------------------------
Home Top: 1048 1225 2048 2141 14497 14692 19997 20195
Home Bttm: 9779 9927 11604 11728 16061 16286 18201 18428
Story Top: 10609 10693 12538 12592 17600 17682 19343 19426
Differences between start/finish ticks
Home Top: 117 93 195 198
Home Bttm: 148 124 225 227
Story Top: 84 54 82 83
Actual speed increase/decrease between first load and next load
Home Top: 47% -1.5%
Home Bttm: 16% -0.9%
Story Top: 35% -1.2%
I ran these tests in Pose 3.5 on linux emulating an m505. I wasn't
able to vary the environment much simply because running these
tests were a little timeconsuming.. but for a 16% to 47% speed
increase, thats not too bad :)
And that's only for images, text should be done in the same way,
that would probably speed up scrolling signifigantly!
This is ofcourse very perliminary.. Right now I'm caching images
through a series of FtrPtrNew() and FtrGet() calls. There are
no checks for free storage space, so there's nothing to stop the
cache from gobbling up all the storage heap. If it crashes, a
soft reset is the only way to fix it. So don't try this on your
own device :)
I've setup a patch of my changes to the latest cvs up at...
http://www.array.org/~adamm/plucker/plucker_cache.patch
--
Adam McDaniel
Array Networks
Calgary, AB, Canada
