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

List:       kde-devel
Subject:    Re: KHTML memory usage.
From:       Oliver Stieber <oliver_stieber () yahoo ! co ! uk>
Date:       2005-06-17 14:56:23
Message-ID: 20050617145623.84120.qmail () web26207 ! mail ! ukl ! yahoo ! com
[Download RAW message or body]


--- Thiago Macieira <thiago@kde.org> wrote:

> Oliver Stieber wrote:
> > Caching should be 'very' easy to implement and will
> > reduce kde bloat. (HINT: it already done for pages
> in
> > the history)
> 
> Do you know that, when you say "very easy", you
> should back that up with 
> code and numbers? If it's very easy, where's your
> analysis of the 
> problem? Where should we implement, in the code,
> that caching? 
> 
> If you haven't done your homework, don't say it's
> "very easy". Your idea 
> has merits, but the way you put it, you're calling
> the current developers 
> incompetents, because they haven't implemented this
> "very easy" thing.
> 

I am saying it is 'very' easy because it already
happens with pages in the history.
I'm attempting to find out what kind of memory
improvements would be possibly before I bother to take
a good look at khtml to work out how hard/easy it
would be. Hard would be if khtml stores the dom in a
tightly integrated was that makes it inaccessible to
the outside world, since khtml is scriptable I very
much doubt this is the case.

There are lots of things that the developers haven't
implemented, even if they are 'easy', if I wanted to
bitch I would choose to implement the idea in Gedion
or IE as it is I'm keen to look at reducing the
working set size of konqueror/khtml and get some holds
on what kind of improvements are possible. I'm not
asking for anyone to do this as I have no problem
writing the code myself.

> Also note that we cannot  (should not) re-request
> from network anything 
> that isn't user-initiated (or an HTTP refresh). For
> example, that means 
> printing should use the cache, not re-request.

Yes, that's why I said use cache.

> 
> So, if Konqueror expired from view old pages, users
> would return to a 
> "This page has expired (even though you did nothing,
> except leave this 
> window/tab open). If you want to see it again, press

No they wouldn't, there's cache.

> F5. Note that might 
> post again the information you had sent."
No need, cache.
> 
> I personally don't think that's a good idea. That's
> what Allan said: the 
> page may not be the same anymore, and it may have
> side-effects.
Well, if the page has changed I wouldn't drop it, I'd
say at least 80% of the pages I view don't change
significantly.

> 
> The only thing I can think of here is to discard
> uncompressed images, and 
> keep only the compressed sources.

Yes, that's a good start, pages with lots of images
are very problematic at the moment, if I can implement
just caching for images first and then look at moving
on to other things if the working set size is still a
problem.

You could even serialise the dom into xml and bzip it
up, so that even pages with changes could be taken out
of ram.

> 
> -- 
> Thiago Macieira  -  thiago (AT) macieira.info -
> thiago (AT) kde.org
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4
> 5358
> 
> 2. Tó cennan his weorc gearu, ymbe se circolwyrde,
> wearð se cægbord and se 
> leohtspeccabord, and þa mýs cómon lator. On þone
> dæg, he hine reste.
> > 
> > > Visit
> http://mail.kde.org/mailman/listinfo/kde-devel#unsub
> to unsubscribe <<
> 




	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail \
http://uk.messenger.yahoo.com  
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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