Re: A tale of waiting

I'm done now. And I've filed as merge request.

And to keep you up to date:

> What is left to do?
>  *  * reimplement directory monitoring. I did never get around adding that code.
This was implemented.

>  * Fix the usage of a filter on the mime type. Currently we don't
> query the mime type (it requires file sniffing after all), so we never
> get matches.
The mime type is now queried, as it doesn't cause big performance
regressions. (see mails from Mathias and Bastien).

>  * File bug(s) about the GValue and interface slowness
>  * evaluate fixed height mode for the tree view, it might make things
> even faster without losing features.
See my mail exchange with Kris.

>  * port search and recent files to GtkFileSystemModel, to get rid of
> more special casing code and make them faster. (Woohoo!)

>  * 50+% of the remaining CPU is spent in GtkTreeView's validate_row().
> I have no clue what that function even does. Is there a way to get rid
> of it?
See mails with Kris

>  * 20+% of time is spent in enumerating the files, with
> lookup_attribute() in gio/gfileinfo.c accounting for 1/3rd of that
> time. There should be a way to use the numeric ids directly instead of
> always looking them up. In GLocalFileInfo it would make sense to me to
> use numeric ids directly. This is an even bigger problem in Nautilus
> (remember: it took 23s in the above test), as it queries a lot more
> attributes.
This is

>  * 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. It would be better if it
> just kept going, so the next call can return already stored files. The
> current behavior can cause excessive sorting in the current
> implementation.
And this is bug


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]