On Tue, 2009-06-23 at 22:16 +0200, Benjamin Otte wrote:
> I have been on a quest to improve performance of the file chooser
First, thanks for taking on this work. "Kill GtkFileSystem" is a very
worthwhile goal.
> * The sort function was called way too often. So I added the option
> to freeze and thaw the tree view. Now the sort function was only
> called once or twice.
Hmm. I haven't read your branch yet, but some things I remember from
profiling the file chooser a while ago:
- It's pretty bad that GtkTreeModel only has "row-inserted" for a single
row, instead of "rows-inserted" --- it gives you automatic insertion
sort, which sucks. So for every single file we read in, the treeview
has quite a bit of machinery to run. This is why (at least before the
GIO work; I don't know about the current state) I made the file chooser
do this:
1. Start with an empty model not hooked to the treeview.
2. Start a timer.
2. Start loading a folder and populating the model.
3. If the timer expires, put the model into the treeview.
4. If the folder finishes loading before the timer expires,
put the model into the treeview.
That's the LoadState enumeration, by the way. Ideally, small folders
will be completely populated into the model before the timer expires.
We can work on making this as fast as possible, and *then* work on what
happens when the poor model actually gets put inside the treeview.
> What is left to do?
> * * reimplement directory monitoring. I did never get around adding that
> code.
Don't worry about this. We can have a custom model, just for directory
trees, once we decide to delve into that for SELECT_FOLDER mode.
> * evaluate fixed height mode for the tree view, it might make things
> even faster without losing features.
Hmmm, do we use the automatic-column-widths thing? That should
definitely be turned off; we can hardcode an initial starting width of
N ems to avoid measuring all the rows.
> * port search and recent files to GtkFileSystemModel, to get rid of
> more special casing code and make them faster. (Woohoo!)
I'm not 100% convinced that this is the right thing to do, but I'll read
your branch before commenting :)
> * The async implementation of g_file_enumerator_next_files_async() is
> very suboptimal, as it stops after N files are enumerated, and waits
> for another call to the function to resume.
See the thing above about the use of a timer. We should be able to call
that function several times before the timer expires, and still avoid
re-sorting because the model is not yet in the treeview.
> And now the obvious question: Should I just merge it to master when
> I'm done with the regressions?
Please give me some time to review this.
Will you be at GCDS? I'd love to do patch review together.
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
