[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: khtml
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-08-16 19:49:26
[Download RAW message or body]

> > back and forward uses the memory cache. See restoreURL() in khtml_part().
> > It feeds the whole file to khtml in a single loop which probably is not
> > the optimal solution UI wise.
>
> At least not for large files. But have you actually done some comparisions
> between loading the file from the disk cache and using this memory cache?

No, but I haven't done it for performance but for correctness. You want the 
history to show the exact same page as the one you got originally. If the 
page is generated by a script the URL can be the same, but the contents will 
be different. 

Something that still needs to be done btw, is that "View source" uses the 
version from memory instead of fetching it from kio_http. Unfortunately I 
stored the page as a list of QStrings, and the current way of showing it 
wants to read it out of a file and will probably expect something in an 
undefined 8 bit encoding.

> It doesn't look much faster too me, and it will use up huge amounts of
> memory in case you have a few large HTML pages in your history. There seems
> to be no limitation on the size of this memory cache since you just store
> them together with the history information. This is a bad idea IMO, since
> konquerors memory usage will just grow the longer you browse. And last but
> not least the page just being loaded will use more memory, since you also
> store the raw html alongside the page.

The solution for the memory usage would be to either limit the history size, 
or remove the cached page when it becomes e.g. number 10 in the history.

Another approach, (for after kde 2.0) could be to not actually store the URL 
in memory, but make an extra copy of the cached entry with a unique index. 
Even if the same URL gets loaded again, this copy will remain unchanged.
It's then up to khtml to delete this copy when it sees fit. A fast way to 
make such a copy is by making use of hardlinks. This seems a bit hairy though.

> > Reload doesn't use this memory cache. Reload is quite slow with images
> > since it fecthes _all_ images again, even if an image was already
> > reloaded for that same page. (E.g. if you have 1 image that gets used 10
> > times on a page, reload will load it 10 times) I thought of a way to
> > solve this problem and came up with the following idea:
> >
> > All images in the cache should be assigned a sequence number. Instead of
> > a boolean saying "reload" all images for this page. You now pass the
> > sequence number and say "reload" all images for this page that have a
> > sequence number that is less than this one and use a cached version of
> > the image if it has a sequence number older than this one.
>
> Sounds like a good idea. Another possibility is to store a timestamp when
> the file was last loaded into the cache with the cached image, and only
> request it again, if this timestamp is older than the time when the reload
> was requested.

Yes, a timestamp is a form of sequence number.

Cheers,
Waldo
-- 
KDE/Linux, if you need solutions instead of hype.

[prev in list] [next in list] [prev in thread] [next in thread]