Thunar responsiveness issues

[Alexis BRENON @Xfce]

Le lun. 8 mars 2021 à 20:56, Viktor Semykin <thesame.ml at gmail.com> a écrit :
>
> Hello Xfce team!
>

Hi,

>
> Some time ago I faced performance issues while using Thunar with my phone
> connected by MTP. The Thunar UI froze often and was not very responsive with
> scrolling, selecting files and other mere file actions. I think it's not only
> MTP but any slow GIO.
>
> I tried to find the cause of issues and this is what I discovered so far. Some
> UI functions make calls that drill down to IO, and freeze while waiting for IO
> to finish.
>
> This is the list of calls I found. The tree structure represents the call stack.
>
> * List model performs IO:
>
>         thunar_list_model_get_value
>         `-thunar_file_get_content_type
>           `-g_file_query_info                         -- [1]
>
> * Icon renderer performs IO:
>
>         thunar_icon_renderer_render
>         `-thunar_icon_factory_load_file_icon
>           +-thunar_icon_factory_get_show_thumbnail
>           | `-thunar_file_get_preview_type
>           |   `-g_file_query_filesystem_info          -- [2]
>           +-g_loadable_icon_load                      -- [3]
>           `-thunar_file_get_icon_name
>             `-thunar_file_get_content_type
>               `-g_file_query_info                     -- [4]
>
> * UI performs IO:
>
>         thunar_standard_view_get_property
>         `-thunar_list_model_get_statusbar_text
>           `-thunar_g_file_get_free_space
>             `-g_file_query_filesystem_info            -- [5]
>
> I believe there are other IO calls too, but I haven't found them yet.
>
> I'd like to solve the issue, but before doing so I wanted to discuss the
> solution with the community. I see two approaches to it:
>
> 1. Ad-hoc solution
>
>     * Prefetch `GFileInfo` with content-type beforehand. This solves [1] and
>       [4], but slows down folder opening.
>
>     * Prefetch file system info in `ThunarFolder` to prevent [2].
>
>     * How to deal with [3]? I have no good clues for now.
>

These solutions look to me like patches or workarounds.
Is it possible to measure the impact of such solutions on folder
opening time and overall memory consumption?
What happens with a folder of 10, 100, or 1000 files?

>
> 2. Async model solution
>
>     * Create a layer that connects GtkTreeModel to async values. When the value
>       is pending the `get_value` call returns a placeholder (blank or "...");
>       when the value is ready return it.
>
>     * Use asynchronous `thunar_file_async_get_content_type` in the list model.
>       This solves [1].
>
>     * Move the code from `thunar_icon_renderer_render` to a new
>       `thunar_file_async_get_icon` that returns the icon asynchronously. This
>       solves [2] [3] and [4].
>
>     This solution increases code complexity because it introduces a new layer
>     and a notion of async values that can be pending or ready.

Asynchronous development always seems more tricky ^^
But I think that, with a good implementation/library/framework, it can
provide a good solution for this problem as well as open new
perspectives (what about folder lazy loading ?)

>
> For the status bar ([5]) it seems just enough to listen to the
> `notify::statusbar-text` signal.
>
> I'm looking forward to the opinion of the community. Do you think any of these
> solutions could be accepted to the Thunar code? Maybe you could think up
> something better? Because I'm not absolutely happy with the approaches above.

Until now, I didn't take part in Xfce development but I like
asynchronous programming, so do not hesitate to ping me for any
feedback.

Kind regards,
Alexis.

>
> Thank you. Let me know if the message formatting is broken and has to be fixed
> somehow.
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev