GNOME Bugzilla – Bug 724247
GtkSourceBuffer: is-loading property
Last modified: 2021-07-05 10:59:28 UTC
When the file loading and saving will be done in GtkSourceView, it would be nice to look at the performances, especially for file loading. There is this wiki page for the file loading, and how to handle the "insert-text" signal: https://wiki.gnome.org/Apps/Gedit/NewDocumentLoading I think we can add an "is-loading" property in GtkSourceBuffer. If something is connected to the buffer _during_ the file loading, it can check the "is-loading" property. If we have instead two signals ("load" and "loaded"), the "load" signal can be missed if the feature is connected to the buffer after the emission of the "load" signal. If we have a feature that listen to the "insert-text" signal and do some synchronous work during the signal emission, it slows down the file loading. One example is the words completion provider. To have a perfect accounting of words in a file, some synchronous work is needed during the "insert-text" and "delete-range" signals. On file loading, the words completion provider can simply clean its words library, and re-scan the entire buffer once the file is completely loaded. I haven't analyzed yet other features that do synchronous work on the "insert-text" signal. If you know other features (the spell plugin, the search and replace, …), it would be nice to analyze them to see if the "is-loading" property is good, or if we come up with something better. With the "is-loading" property, it is more work for the other features (the features must connect to the notify signal, and handle that correctly), but I don't think performance improvements can be done easily without this additional work from the other features.
On the wiki there is a proposition to disconnect the buffer from the view during the file loading. If GtkTextView slows down the file loading, then it can be a good idea. But other features like the words completion provider can anyway be connected to the buffer while the buffer is disconnected from the view. So it doesn't solve all the problem.
For the search and replace, some work is also done synchronously on the "insert-text" signal, to update correctly the occurrences-count property. So it can also potentially slow down file loading. A simple solution for the search and replace, with the is-loading property: - when the file loading is started, all the buffer contents is removed, so the search is cleared (for the "delete-range" callback, there is already a special case when all the contents is removed); - during the file loading, do not search the buffer; - when the file loading is finished, start to search the buffer. I think something similar can be done for the syntax highlighting. And for the syntax highlighting, this can already be done externally, by calling gtk_source_buffer_set_highlight_syntax(), i.e. disable syntax highlighting during file loading.
See also: https://wiki.gnome.org/Projects/GtkSourceView/InsertsDeletesPerformances
Set status to UNCONFIRMED, since it's not yet clear what to do. See the wiki page.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gtksourceview/-/issues/ Thank you for your understanding and your help.