[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 16:00:46
Message-ID: 20050617160046.71594.qmail () web26202 ! mail ! ukl ! yahoo ! com
[Download RAW message or body]


--- Chris Howells <howells@kde.org> wrote:

> On Friday 17 June 2005 15:25, Oliver Stieber wrote:
> > <rant>
> > what a load of rubbish,
> 
> Naturally, because one of the developers that spends
> larges amounts of time 
> writing it knows far less than you, someone who has
> just appeared on 
> kde-devel.

I was referring to letting the kernel manage memory
when it can be managed many times better by the
application. This not just the case for KHTML it is
the case for the majority of applications. I have 20
years experience developing and have developed a large
number and range of applications for a variety of
operating system and I always try to remove any
bottlenecks that may be in the application.


> 
> > (I've tried to find out but appear to have hit a
> brick
> > wall) many times larger than plain HTML and jpegs.
> > If khtml managed it's memory usage properly
> instead of
> > being lazy and (oh the kernel manges that kind of
> > stuff) then there would be no need to the kernel
> to
> 
> Do you actually have any basis for your claims other
> than vague speculation? I 
> guess not "I've tried to found out but appear to
> have hit a brick wall".#

Well...  I've written a number RTF style editors
before, so I have a reasonable knowledge of how they
work.

For HTML I would expect the following happens.

1: The HTML is downloaded.
2: The HTML is parsed and converted into some internal
structure that provides more regular faster access. in
the case of HTML this would be the dom tree. The DOM
tree may actually be smaller than the original HTML
because tag names get replaced with objects.
3: The layout engine then uses the DOM tree to
generate a page layout, I usually keep line and block
information in the layout for performance that you
wouldn't expect to find in the DOM tree.
4: A number of QT GUI objects are then created to
layout the page.
5: Images are downloaded in a compressed format, and
converted into uncompressed RGB QT images, and
possibly also XBitmaps.

3,4 and 5 may or may not add a significantly more data
than 1 and 2 require to store the extra information.

I am trying to ascertain if it is worth my while
dropping the elements in 3 4 and 5 when memory becomes
scarce and recreating then again when the user
requires them.

I already know that it wouldn't take a that much CPU
time to regenerate the data in 3,4,5 base on my
experience of using Konqueors' history, which I have
been told does not store the DOM so I know that it is
recreated.

> 
> -- 
> Cheers, Chris Howells -- chris@chrishowells.co.uk,
> howells@kde.org
> Web: http://www.chrishowells.co.uk, PGP ID:
> 0x33795A2C
> KDE/Qt/C++/PHP Developer: http://www.kde.org
> > 
> > > 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]