Source code highlighting makes main editor very slow

[rillig]

Using Poedit 3.0.1, I noticed that the source code window uses highlighting. Very nice.

The downside of highlighting is that whenever I switch to another message in the main window, the UI freezes for at least 1.0 seconds. I'm currently translating GCC, and gcc.cc has 11_000 lines. In general, GCC has rather large source files.

Could you move the highlighting code into a background thread so that I can continue translating at full speed, without being slowed down by the source code window?

To reproduce, clone https://github.com/gcc-mirror/gcc and edit gcc/po/de.po with an open source code window.

I didn't find a way to temporarily disable highlighting, to verify that it's indeed the highlighting code that slows down Poedit. At least if I close the source code window, I can translate at full speed again.

[rillig]

I just noticed that the source code window slows down editing even when the window is not visible at all because it is below other windows. That might be worth optimizing as well.

[vslavik]

For once, this isn't about gcc having huge PO files, but about having huge source code files.

This is specific to Windows and IE11 renderer. The delay is two fold: loading the source file freezes the main thread, and then highlighting it does the same. This is because the IE11-based WebBrowser control does everything on the main thread.

Highlighting is done in the web view with Prism.js, so we have limited control over the thread it runs on. So fixing this won't be as simple as offloading to a worker thread. Possible approaches, with roughly increasing level of complexity:

1. Perform highlighting asynchronously, see this article — at the cost of additional flicker and probably won't eliminate the first delay in parsing, but if it works, it's the easiest thing to do
2. Switch to Edge-based WebView2 — its modern architecture offloads the work into another process
3. Rework completely to do the highlighting outside of the webview control — ideal (also has the advantage of completely eliminating any syntax highlighting flicker), but also the most work

I just noticed that the source code window slows down editing even when the window is not visible at all because it is below other windows. That might be worth optimizing as well.

(It's hard (I'm not even sure if possible) to detect a visible, but obscure window, so this is unlikely to be worth trying.)

[vslavik]

Perform highlighting asynchronously, see this article — at the cost of additional flicker and probably won't eliminate the first delay in parsing, but if it works, it's the easiest thing to do

Option 1 won't work — significant amount of time is spent in just loading the source file, so it's not going to help sufficiently.

[rillig]

Thank you very much. The resulting commit looks reasonably simple and nicely hides all the work and afterthoughts that went into making it that simple. :)

[vslavik]

The resulting commit looks reasonably simple and nicely hides all the work and afterthoughts that went into making it that simple. :)

You have no idea :) I spent most of a day on that if (m_usesMSIE) line - debugging weird scrolling issues that were somehow (still no idea how) related to loading files from disk. Embedding browsers is fun.