Thunar responsiveness issues
Alexis BRENON @Xfce
brenon.alexis+xfce at gmail.com
Mon Mar 8 21:48:38 CET 2021
Le lun. 8 mars 2021 à 20:56, Viktor Semykin <thesame.ml at gmail.com> a écrit :
> Hello Xfce team!
> 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:
> `-g_file_query_info -- 
> * Icon renderer performs IO:
> | `-thunar_file_get_preview_type
> | `-g_file_query_filesystem_info -- 
> +-g_loadable_icon_load -- 
> `-g_file_query_info -- 
> * UI performs IO:
> `-g_file_query_filesystem_info -- 
> 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  and
> , but slows down folder opening.
> * Prefetch file system info in `ThunarFolder` to prevent .
> * How to deal with ? 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 .
> * Move the code from `thunar_icon_renderer_render` to a new
> `thunar_file_async_get_icon` that returns the icon asynchronously. This
> solves   and .
> 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 () 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
> Thank you. Let me know if the message formatting is broken and has to be fixed
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
More information about the Xfce4-dev