[Evolution-hackers] Re: shutdown performance ...

[Not Zed <notzed ximian com>]

Hi Michael

On Thu, 2003-10-02 at 09:11, Michael Meeks wrote:
> Hi there,
>
> 	I was just shutting down evo. on my machine under some considerable
> load and since I've been wondering about performance (particularly on my
> slow-disk'd system) for some time I did an strace:
>
> 	http://primates.ximian.com/~michael/evo-shutdown-log.txt
do you know if thats showing subthreads too?

I really doubt all those little files and fsyncs should thrash the disk too much (particularly since they're serialised), something like a re-indexing scan or mbox sync done multiple threads however, would be a nasty hit.

> 	I'll try and get a better one in a minute ( this only caught the end of
> the thrash, and only part of that with -ttt ).
>
> 	Either way; it seems there is a per folder loop:
>
> open("/home/michael/evolution/config/.#et-expanded-file:_home_michael_evolution_local_Mail_subfolders_bonobo", O_WRONLY|O_CREAT|O_TRUNC, 0600) = 42
> write(42, "<?xml version=\"1.0\"?>\n<expanded_"..., 64) = 64
> fsync(42)                               = 0
> close(42)                               = 0
> rename("/home/michael/evolution/config/.#et-expanded-file:_home_michael_evolution_local_Mail_subfolders_bonobo", "/home/michael/evolution/config/et-expan
> ded-file:_home_michael_evolution_local_Mail_subfolders_bonobo") = 0
> unlink("/home/michael/evolution/config/hidestate-file:_home_michael_evolution_local_Mail_subfolders_bonobo") = -1 ENOENT (No such file or directory)
> write(3, "\231\7\2\0}\10\343\0006\7\2\0|\10\343\0\231\7\2\0\342\27"...,
> 2044) = 2044
> open("/home/michael/evolution/.#searches.xml", O_WRONLY|O_CREAT|O_TRUNC,
> 0600) = 42
> write(42, "<?xml version=\"1.0\"?>\n<filteropt"..., 2780) = 2780
> fsync(42)                               = 0
> close(42)                               = 0
> rename("/home/michael/evolution/.#searches.xml",
> "/home/michael/evolution/searches.xml") = 0
>
> 	It re-writes searches.xml each time around the loop; and does an fsync
> - causing some nice head movement ;-) is it easy to make at least that
> part of the write-out atomic over the whole set of folders - currently
> it seems to do it once per folder; and/or is that worth doing?
Actually I have no idea why it would be writing searches.xml so many times, strictly it should only write it when something changes, i.e. you add a new search.  It may be that it does some sync every time the widget is shutdown, which it probably shouldn't.

The etable stuff, I _think_ is handled internally by etable.  The hidestate gets written when the folder view gets shut down, yeah it might make sense to have this part of the de-activate codepath.

> 	Also; given that it's always going to be painful seek-wise to store the
> expanded state (which I assume is what it is) in a separate file per
> folder; is it possible to minimise / UI-tie the update ? ie. can the
> state be serialised when we switch away from a folder view (and thus
> stop expanding/contracting nodes) ?
>
> 	Obviously I guess this may all be much improved in the evo. development
> stuff; I'm only using 1.4.5.
I can probably almost certainly say it hasn't ... :)

Actually I think some vfolder stuff that got put in might make it worse (if you have lots of vfolders anyway).  Oh well, something to address eventually.