Re: [Nautilus-list] Nautilus2 performance - hotspot ...

[Michael Meeks <michael ximian com>]

Hi Seth,

On Wed, 2002-01-23 at 12:51, Seth Nickell wrote:
> I'm pleased to report that Nautilus 2 is performing very quickly
> relative to Nautilus 1!

	Another thing that came out of my Gnome 2.0 nautilus optimization spree
- was that I recollect John Harper coming and optimizing bonobo thus:

2001-02-24  John Harper  <jsh eazel com>

	* bonobo/bonobo-ui-util.c (write_byte, read_byte): rewritten to
	use lookup tables to do data conversion. Also made inline
	(write_four_bytes, read_four_bytes): made inline

	To make stringification of pixmaps fast - curious I thought at the time
- anyway, it turns out that the way the 'history' feature works in
nautilus 1.0 was like this:

	nautilus-window-manage-views.c organises the master history list as
NautilusBookmarks - then when it determines that it might have changed,
it broadcasts this list to all the NautilusViews.

	So - only 1 component - the history view is interested in this data,
but it is sent to every NautilusView ie. all the sidebars, and the main
view. And not only that, but to every NautilusView in every open
NautilusWindow.

	So what you say ? well - the data sent is not small, it includes the
stringified pixbuf (the icon for the URL in the history view), and the
number of history items can be up to 50 items.

	So what - it's a lot of data - but we need to send it surely ? well,
the problem is that the same data is sent multiple times per URI change,
to every view on every nautilus window.

	So what you say - it's a 'oneway' method, which means that the main
Nautilus process won't block. Well - true, up to a point; as long as
less data than the socket buffer is pushed there should be no immediate
context switching / blocking waste / nastiness. But in fact there is
really rather a lot of data sent.

	Anyhow - so this is _mostly_ fixed in Nautilus 2.0, by making the
"history" item a property - only listened on by the history view. In
fact nice speedups could probably be got more simply by hacking the IDL
and nautilus-view-frame only to notify views that are interested in the
data.

	So - I'm currently poking with 2.0 trying to reduce the number of
redundant re-sets of the history, since it's still one of the biggest
transfers I see; incidentally the new non-blocking 'oneway' buffering
may also be helping us here by allowing us not to block even if we do
decide to send gigantic amounts of data to a oneway method.

	If people are still interested in optimizing Nautilus 1.0 that might be
a very fruitful place to look.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot