Performance expectations of TM4E #560
Replies: 3 comments 4 replies
-
No clear plan as I don't think anyone deeply "plans" for TM4E, most active contributors are reactive to issues, updates and so on, but no one has taken an initiative to do a clear performance audit and improvements. Am I right @sebthom or do you have some secret plan?
I believe that TM4E colorizes the visible lines with higher priority, and then it will try to colorize other invisible lines in a background work. But it is assumed that coloration of background is "cheap" and not locking the UI Thread.
You can report an issue about it as it should be enough information with the stack traces to act on that particular issue, the lock conditions can probably be relaxed (ie only lock if we don't already have data for the line or if the line is marked dirty, but return immediately otherwise). |
Beta Was this translation helpful? Give feedback.
-
I created an issue about the lock as that seems to make the situation worse - #561 |
Beta Was this translation helpful? Give feedback.
-
|
After #540 I implemented a considerable amount of performance optimizations. Please give the latest snapshot a try. The main issue I currently see is that when opening very large JSON files the LSP4E freezes the UI while trying to populate the outline. |
Beta Was this translation helpful? Give feedback.
-
|
I tried without matching LSP4E language server to try to isolate just to TM4E's contribution. Perhaps other languages are not as badly affected, I note that the CPP language is ~16,000 lines, while dart is ~500 lines |
Beta Was this translation helpful? Give feedback.
-
You sure did - thanks! The time to colorize the whole file went from ~15 minutes wall time to ~2 minutes and it does not lock the main thread anymore.
I don't see this happening in practice. If I scroll to the end of the file immediately after opening, it still takes ~2 minutes for the last line to be colorized. |
Beta Was this translation helpful? Give feedback.
-
|
I tried the AArch64GenAsmMatcher.cc file with the latest snapshot. I cannot reproduce the locks. However, I see that the org.eclipse.ui.internal.genericeditor.DefaultWordHighlightStrategy freezes the UI doing: This happens on every click inside the editor. That is another issue I also saw when opening large JSON files. |
Beta Was this translation helpful? Give feedback.
-
|
I am going to close this discussion for now as with @sebthom's recent improvements the bulk of the problem has gone away. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I am working on the CDT LSP plug-ins and we are currently using TM4E to support syntax highlighting.
I am wondering what the performance expectations of TM4E are? Is there a plan on how to support large files? For example, in VSCode if I open the attached file it only colorizes the visible lines, but in TM4E I think it is trying to colorize the whole file.
The behaviour I see today is that on larger files this is very slowly and runs substantially on the UI thread, causing the entire Eclipse to become unresponsive. It took approximately 15 minutes before the UI returned to normal use.
Here are some stack traces - the UI thread usage may be dominated by waiting for a lock?
Here is a gzipped file that experiences the problem (part of LLVM Project) - tested with Eclipse IDE for C/C++ 2023-06 with TM4E language pack 0.2.0.202305071450 installed and opening file in generic editor.
AArch64GenAsmMatcher.cc.gz
Opening the same file in the C/C++ Editor turns on scalability mode which disables some of the more advanced features (like full semantic highlighting) but the syntax highlighting works seemingly instantaneously.
Beta Was this translation helpful? Give feedback.
All reactions