Re: [Nautilus-list] Optimizations

[Michael Meeks <michael ximian com>]

Hi Alex,

On Mon, 2002-03-11 at 17:52, Alex Larsson wrote:
> Sure. If we have a loop like this we can fix it. But in general the policy 
> in nautilus for strings is that all getters return a copy of the string. 
> This makes for more robust and consistant memory management handling, 
> something i think is worth .9% performance. 

	Sure - I don't believe that policy can really be the cause of any
slowness. Algorithmic optimizations will be far more significant.

> What I meant by it being hard to fix was that there were no "obvious" 
> hotspots. 

	There are still some things that I really don't understand, that may
well be fruitful to persue. Watching the ORBIT2_DEBUG=traces is
_extremely_ useful, I would recommend watching it roll for anyone that
hasn't seen it before - although be aware that the output can be
confused with that from other components if you fork activation on the
same console.

	I see some curious things like:

p22582 1015922395.22835 : ([0x80e1f88])->lookup_with_schema_name
('/desktop/gnome/sound/enable_esd', 'en_US', 1, ) =>: { d=0 v=0x0 } out:
('', 0, 1 ) 1015922395.23552 
p22582 1015922395.105882 : ([0x80e1f88])->lookup_with_schema_name
('/desktop/gnome/sound/enable_esd', 'en_US', 1, ) =>: { d=0 v=0x0 } out:
('', 0, 1 ) 1015922395.106618 
p22582 1015922395.137386 : ([0x80e1f88])->lookup_with_schema_name
('/desktop/gnome/sound/enable_esd', 'en_US', 1, ) =>: { d=0 v=0x0 } out:
('', 0, 1 ) 1015922395.138112 

	Indeed, there's really quite a lot of that one going on as you
mouseover things; it'd be good to have an eel_auto_boolean thing there.

	Again, the history change is sent ~four times - for reasons I don't
understand, and that is a big transaction - worse it's not the same
data, we blast the history off and then we update the contents of the
location [ stripping eg. a file:/// prefix off it ] and then send it
again, only it's not easy to detect that that happened and I think it
happens idly. Oh, and finally - it's pointless having the history list
broadcasted even to the single sidebar, since we can fetch the property,
and listen for that explicitly when the history sidebar is actually
mapped - which might save some time; better still would be a more
explicit way so that the container doesn't construct the data from the
structure [ with stringification ] repeatedly per view, but did it once
and passed it in the 'history_list_changed' signal, ie. add a CORBA_any
parameter to history_list_changed, instead of doing the get_history_list
repeatedly in different nautilus-view-frame.c (send_history)'s.

	Although we do a vast oaf query the first time we change directory,
that is subsequently cached, so we have no bonobo-activation traffic
going on on a directory change.

	Another thing that is interesting is that we change the throbber state
a good number of times, it gets turned on and off ~twice (4 calls)
during the process of changing directory - which is strange, and may
point to some issue lower down.

> This was done using oprofile, so I have no call stacks. Only the flat 
> profile.

	Oh - shame. Eazel prof is quite nice with it's cumulative view, that
can help.

> Yes. This sounds like a good idea. Especially the places that read largish 
> xml files. I don't think it matters for e.g. reading the icon xml files.

	Sure, it's really good to have you working on this,

	Regards,

		Michael.

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