[Evolution-hackers] evolution-1.4 method trace ...

[Michael Meeks <michael ximian com>]

Hi there,

	So - I ran the method trace on evo-1.4 - and (unfortunately) we get to
see in-proc methods as well which slightly obscures the picture but
anyway its here:

	http://primates.ximian.com/~michael/evolution-log

	A simple grep for 'lookup_with_schema_name' shows that we do a good
number of consecutive round-trips to gconfd; particularly:

	Perhaps doing a one-time recursive cache lookup of:

	/apps/evolution/summary/		x11
	/apps/evolution/shell/view_defaults/	x8
	/apps/evolution/mail/display/		x12
	/apps/evolution/calender/tasks/		x5
	/apps/evolution/calender/display/	x16

	Would save ~50 round-trips to gconfd and presumably save a number of
milliseconds on startup / view switch.

	It's also easy to fix with a few:

	gconf_client_add_dir (gconf_client_get_default (),
	                      "apps/evolution/summary",
	                      GCONF_CLIENT_PRELOAD_RECURSIVE,
	                      NULL);

	or similar - scattered around.

	I forgot to start-up a full-blown editing gtkhtml; I imagine that does
some similar things;

	When the calendar starts doing things in the Log; we notice the string
truncation in the trace [ which mercifully obscures most of my calendar
data ;-], and we see a ~large number of serial synchronous:

	GetObject (N); GetObject (N+1); etc.

	calls which IMHO would be prime target for a GetObjects ({N, N+1}) type
method. [ I was scrolling up and down my calendar there ], but even so
one GetObject set was 5.064958 to 5.086564 = ~22ms - which wouldn't
explain the really noticable delay with calendar scrolling - perhaps
that's related more to idle / canvas effects [ assuming it uses the
canvas ;-].

	We also seem to invoke some methods on non-existing objects - whether
that's a feature or not I know not.

	The addressbook seems to push it's data as a sequence in growing
chunks; 20,40,80,160 elements etc. which looks good; the largest taking
~115ms from request -> response - possibly some scope for optimising the
'large request/reply' support in ORBit2 there - we can send a set of
GIOP fragments instead of a huge slurp in future perhaps.

	Anyway; I hope that's interesting,

	Regards,

		Michael.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot