Performance is not neglected, it's something we always keep in mind when doing something, or the app would be way slower than it is now.
There are a few known issues: the tags, and there's an issue to track this.
And the second that I know of appears to be due to certain plugins that make a lot of API calls. I still don't know how to best handle this - just throttling them, might also break some plugins that work well. Or maybe the throttle mechanism needs to be improved.
I agree.
There are two types of performance issues: the first is being inoperable and the second is being inefficient. Already reported performance issues are almost the former (e.g. Issue #4251 and Issue #5563). Of course, the former has higher priority and should be fixed immediately. For the former, I think Joplin's issue tracking ecosystem works well.
In the other side, the latter is difficult to report as issues. There are few chances to recognize others' impression like this topic. As mentioned in the summary, sometimes users don't notice they suffer from some performance issues.
My suggestion is to pay attentions to the latter issues and to improve users' UX.
For example, from the collected measurement results above, it seems that there are unreported performance bugs as issues. By fixing them, there is a chance to accelerate note switching several times faster.
Technically speaking, API throttling is suitable not for efficiency but for preventing inoperability in the application software layer such as Joplin. It is just a fail-safe mechanism. So, its configuration should be very conservative.
For example, there are two representative cases: Link Graph UI plugin and Note Tabs plugin.
In the case of old Link Graph UI plugin, the app was almost inoperable because of too many API calls (ref: Issue #5563). API throttling will be very helpful in this situation.
In the case of Note Tabs plugin, when API throttling was first introduced, the plugin was broken by API throttling. Although the plugin creates relatively many API calls and has a room to be optimized, it is not inoperable but only inefficient. It is not the role of API throttling to encourage more efficient API usage.
Additionally, since CPU performance varies in a wide range, it is danger to use some configuration suitable for some PC to other PCs. So, the configuration should cover only evident abnormal activities for any PCs.
I see your point but I still think that API throttling is a good way to improve the app reliability without restricting plugins too much. The initial algorithm was based on my testing with a few clearly faulty plugins - they were making thousands of requests and keeping the app permanently at 100% CPU. So the throttling would slow them down and eventually make them stop working. In those particular cases that was fine - it just means that the plugin developer needs to fix that bug. Because the plugin would stop working they'd get report and could find where the issue is thanks to the error log.
The problem indeed is that it also affects plugins that work fine such as the Note Tabs plugin and others. Those as I understand make a lot of requests for a short time, then they are idle. Because of these many requests they were throttled and stopped even though it wasn't necessary.
So instead I've been looking at the "token bucket" algorithm, which should work better for our case. It should allow plugins to make bursts of requests for a short time (again like the Note Tabs plugin) without any restrictions, while throttling faulty plugins that make many requests per second, all the time.
Anyway that's what I'm currently looking at, but if you have any idea about other solutions I'd be glad to hear it.
Have you considered disabling pagination for plugins? I suspect this may be the main reason for sending lots of requests within a short time window. This certainly was the case for the quick links plugin.
Hmm, yes maybe but we still need to have a limit, because if a plugin requests, for example, the body of all notes it will be GBs of data and that would probably break something, either the IPC call, or JSON parsing.
But maybe we could increase the page size to a higher number. I think it's 100 now, so 1000 for instance might help without getting any crash.
Maybe I didn't write it right, I stated API throttling is not bad for fail-safe and reliability. And, I agree token bucket is a good choice.
However, to achieve a responsive UI is a different matter, and another way is needed. One of the biggest bottleneck of the UI response is the avalanche effect of re-rendering triggered by plugins, as shown in the figure above.
It's funny, even though I don't use joplin as a client, I also find it slow when I open a note via the joplin api. Although this has been greatly improved in 0.7.0, the performance optimization of joplin itself is of course also interesting, especially since the current project of joplin is already so large