Thunar responsiveness issues

[Alex]

Thanks for bringing it up, and for your proposals !

Regarding your chain of calls: Looking into
"thunar_file_get_content_type" shows that theoretically,
"file->content_type" already should be cached ... which seemed not to
work for your usecase.

IMO we should debug that first before starting to change the complete
architecture.

After that, if MTP device performance is still bad, I think a good next
step would be to check how expensive each of the calls is (how long did
it take?). Possible we dont need to fix all of them, but just the most
heavy one.

Though if you have some easy fix for [5]
"thunar_list_model_get_statusbar_text", please give it a try !  If it
does not add too much complexity, I'll merge it.

... I think we should better continue the discussion on gitlab .. could
you please open an issue for it ?

Cheers,

Alex(xcons)



Am 08.03.21 um 21:48 schrieb 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
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev