The following bytes were arranged on 13 Oct 2012 by cj :
> In article <[email protected]>,
> Rob Kendrick <[email protected]> wrote:
> > I would expect to see the most significant improvement on a
> > StrongARM RiscPC using the on-board IDE where the IO is a
> > significant bottleneck and time to decompress insignificant.
>
> I would think there would be a significant speed up on a BB system
> using a USB pendrive as the drive. This is very slow.
I can't see much difference in the loading time between 2.9 and #463 on
an ARMini myself.
The thing which is *really* annoying about using NetSurf on a USB drive
is the enormous amount of time it takes to quit - up to thirty seconds
on a bad day! This seems to be dependent on the amount of browsing done
beforehand. I've tried cleaning out the cookies and turning off history
collection, and that made it slightly better, but that can't be all of
it.
The last time I examined NetSurf's log file after quitting I saw that
the lines which were taking up the vast majority of the time since the
quit request was received were a set of repeated calls to
bitmap_save_file(bitmap) in riscos/bitmap.c. This seems to be the result
of the following loop in bitmap_quit():
void bitmap_quit(void)
{
struct bitmap *bitmap;
for (bitmap = bitmap_head; bitmap; bitmap = bitmap->next)
if ((bitmap->state & BITMAP_PERSISTENT) &&
((bitmap->state & BITMAP_MODIFIED) ||
(bitmap->filename[0] == '\0')))
bitmap_save_file(bitmap);
}
I'm at a loss to understand exactly what 'bitmaps' NetSurf could have
'modified' in the course of the session, or where it's 'saving' them to.
All I know is that this is a horrendously inefficient operation!
--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
