Sublime Forum

Sync versus async Sublime Text callbacks performance

#1

Let us take code as an example:

class MinimapSetting(sublime_plugin.EventListener):

    def on_load(self, view):
        show_minimap = view.settings().get('show_minimap')
        if show_minimap:
            view.window().set_minimap_visible(True)
        elif show_minimap is not None:
            view.window().set_minimap_visible(False)

It is used the sync callback, instead of the async version (on_load_async).

Let us supposed someone did a Find and Replace in a project, which replaced things in 1.000 files. Therefore, Sublime Text will open 1.000 views. In this context, are on_load and on_load_async exchangeable? Or does on_load_async is more costly/expensive, if it will be called 1.000 times in a row?

Note: Disregard other scenarios where on_load_async must be used because it holds a slightly expensive code, which could actually be better running off in a separate thread, other than blocking the Sublime Text main async thread.

0 Likes
#2

there is usually an overhead with async methods, but as ST uses one thread for the async callbacks, presumably it wouldn’t be too noticeable. More to the point, why would each view get activated automatically? They can’t all have the focus at the same time…

1 Like
#3

I wrote it wrong. The callback I am referring is on_load and on_load_async, which will get called for every view opening.

0 Likes
#4

If I had to guess I would say that all else being equal, for the user the non async version would have more impact because if it had to trigger 1000 times sequentially, the UI would probably seem to slightly hang/hiccup become less responsive, whereas if it was done with the async version, they’d happen off the main thread.

I can’t imagine that the overhead of one thread versus another handling callbacks in order would amount to that much overall, but the best way to know for sure would be to try it and see what happens; if we recall our Knuth:

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”

1 Like
#5

I am looking over things like this because if I do search and replace thing (which opens 1000 fies or more) on my full installation of Sublime Text, it hangs for so much time, I have to kill it. While, doing the same thing on a vanilla installation hangs Sublime Text very much less.

0 Likes
#6

Well, as a general rule of thumb, doing something always takes more time than doing nothing. What I was getting at is that it’s of potentially less importance which event type has more overhead without actually tracking what the event itself is doing.

That is, if the contents of the event handler is sleep(60), whether the dispatching mechanism takes a few milliseconds more one way or the other probably doesn’t matter as much in the grand scheme of things; what’s going on is already going to be slow.

Worrying about which of the two mechanisms is more performant without having tracked what’s actually happening sounds suspiciously like an XY problem. Have you tried doing something like this on a full install but in a way that it only opens a couple of hundred files, followed by using the plugin profiler to see which is taking the most time?

2 Likes
#7

That is on my TODO list.

0 Likes