-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Noticeable lag when typing in larger code blocks #33
Comments
It's interesting there still some slowdown, even when font-locking is disabled. I never worked with big code block in adoc-mode, which is probably why I didn't notice the problem. @TobiasZawada can speak more about the current implementation, which I believe came straight from org-mode, so I was expecting similar performance. Running the Emacs profiler will give you some insights where exactly the slowdown is happening - see https://www.gnu.org/software/emacs/manual/html_node/elisp/Profiling.html for details. |
@bbatsov Notice: I am out of office for about three weeks. I don't know whether I have a chance to go online in this time. |
I can try out the Emacs profiler and also compare with the org-mode implementation. |
Ok, I've lots to learn, but I have discovered that if I totally disable font-locking via |
This is how I'd start to debug this issue. Add this in
Then run Eldev like this (Lee's initial problem was that Emacs was compiled without X support as I understand, for me this worked fine immediately):
In the buffer, find a
Obviously, a third of a second (0.07 + 0.26) is way too much. I don't plan to dig deeper and try to solve the issue myself, I'm just trying to demonstrate how it is possible to use Eldev to [try and] figure out such problems. In the above output you can see that |
Thanks @doublep!
Yup, after I switched to emacs with X support, eldev worked fine. I spent a lot of time trying out font-lock-studio, font-lock-profiler, the emacs profiler, comparing org's implementation to adoc-mode, etc. After a while it felt like I was pulling at straws without any approach I understood that would help to diagnose this issue. At that time I decided to pause and work on other things. If nobody else dives in, I might shake off my feeling of defeat and try again. 🙂 |
@lread As I already mentioned in a comment of this issue I am currently in vacation. Depending on how much spare time I have next week I will fix this issue. The most likely cause is that for each edit of the code block the full code block is refontified. I am just using the phone to write this message. So I cannot study how Orgmode avoids that. I guess font-lock-studio is the best tool for the investigation. |
Thanks @TobiasZawada, I look forward to learning from your fix! |
Even if Orgmode seems to do fine in our case, there have been complains: https://emacs.stackexchange.com/questions/46561/org-mode-9-too-slow-with-long-code-blocks |
1 similar comment
Even if Orgmode seems to do fine in our case, there have been complains: https://emacs.stackexchange.com/questions/46561/org-mode-9-too-slow-with-long-code-blocks |
- Set text property `font-lock-fontified` for fontified code blocks - also fix compiler error by quoting lambdas with sharp quote
Hey congrats @TobiasZawada! How did you pinpoint the cause? |
@bbatsov do preview builds get automatically created on melpa? |
@lread Yeah. Feel free to test the latest version there. |
@lread You asked how I determined the cause of the problem. |
I didn't know about https://github.com/Lindydancer/font-lock-studio - pretty cool tool! |
Thanks for the info @TobiasZawada. Am I doing something wrong? I still see some serious lag. After doing an I double-checked I am getting the current adoc-mode:
Did lag go away for you @TobiasZawada when you tried my test? |
@lread I did check with the original test and there was no longer a recognisable time lag in the fontification of the source block. When I find time today in the evening I will doublecheck. So, until this is cleared, I reopen the issue. |
Thanks very much @TobiasZawada! |
Replace `re-search-forward` by `adoc-kwf-search` in font-lock keywords. `adoc-kwf-search` continues search if the adoc-code-block text property is set at the matching position.
Looks like the current implementation of the keyword search in adoc-mode is just slower than that one in Orgmode. Orgmode also applies other keywords to source blocks. The last commit introduces @lread Would be nice if you could test this version directly with https://github.com/bbatsov/adoc-mode/blob/SrcBlock/33font-lock-fontified_missing/adoc-mode.el |
@bbatsov When I replace the start of
and add a closing parenthesis at its end, the fontification of the test file becomes faster than the Orgmode version. (I've got another test case where I put the full text of The fast fontification of the adoc-buffer with the modified As I already mentioned above, I was wrong in assuming that stretches of the buffer that are already marked by the text property I am slowly running out of spare time. Nevertheless, I'll try my best to dig deeper into the problem in the remaining time. |
@TobiasZawada Thanks for the update and no rush. I don't have much time for After Emacs 29 is out it might be nice to consider using something like |
@bbatsov I put here the result of
I've got a time-out right now. Let us see whether I have spare time in the evening. |
@bbatsov @lread The problem is that We have to find a better modified start point than |
Nice sleuthing @TobiasZawada! Limited to code blocks, if so why?My original issue reproduction showed this happening within larger code blocks. Or, if the lag occurs in code blocks only, then do you know why? Keyword ExperimentFor all these tests I used my original "Steps to reproduce the problem" from this issue. I did many experiments, but for one, I experimented with commenting out adoc-mode keywords. (adoc-kw-llisti 'adoc-labeled-normal 1) If I comment this one out lag is reduced but only by a bit. Hello;; What's up? A perhaps interesting thing, is that I still get significant lag with only... '(adoc-fontify-code-blocks)
(adoc-kw-llisti 'adoc-labeled-normal 1) ...uncommented (all others commented out), I get enough lag for things to feel unpleasant. If I then disable
...no perceived lag. So why does |
@lread It is very nice that you do more tests than me.
My working assumption is that the problem hits code blocks most because code blocks may be relative large and the factor introduced by And now I have an urgent request for you: Could you please test the newest version of https://raw.githubusercontent.com/bbatsov/adoc-mode/SrcBlock/33font-lock-fontified_missing/adoc-mode.el 1st with your standard test and 2nd with everything that comes to your mind. Thanks in advance. The ERT tests are fine. And my personal performance test that compares the fontification time of an adoc document with that one of an org document each with a code block containing the text of |
There is still a similar construct in |
@TobiasZawada, happy to give your branch a whirl. My testing process is painfully manual. I just spent some time trying to automate it but did not find a way to simulate real key presses as if I had typed them at the keyboard myself. Ideally I'd like to simulate the keypresses and also measure any lag. But back to manual testing for now: Woah! Results seem very impressive! (Reminder to self and maybe tip to others: https://gifcap.dev/ seems like a nice way to generate screen recordings). |
@TobiasZawada, I have updated my doom emacs config to use your branch. For doom emacs lurkers:Edit
To rebuild, you'll need to: $ rm -rf ~/.config/emacs/.local/straight/build-28.2/adoc-mode
$ doom sync |
Also add ert test for keyword-replacement
@bbatsov @lread Lee Reed has comprehensively tested the branch (with exception of the change on I have added a working ERT for the not so intensively tested corner case So we should finally be ready to merge !37. |
You are probably right. But we need the keyword based font-lock for Emacs versions < 29, if you do not want me to fork my own backwards-compatibility version again. I cannot switch from 27.1 to 29 at my office computer, since that computer is managed by the IT of the company and Emacs is more like accepted than wanted by the IT. In the early phase of the Tree-Sitter version we also need it as fallback for people who have problems with the new version. |
@bbatsov I think I open a new branch for restructuring |
FWIW, trying with emacs 29.1 now. |
I should have some time to take a closer look over the course of the week, so let's drive this to the finish line. |
That sounds great, thanks to you both! |
Replace `re-search-forward` by `adoc-kwf-search` in font-lock keywords. `adoc-kwf-search` continues search if the adoc-code-block text property is set at the matching position.
Also add ert test for keyword-replacement
I think everything is done here. |
Thanks!
First, thanks for maintaining adoc-mode! I very much appreciate it!
Discovery
I'm a doom emacs user.
I noticed the lag when using adoc-mode I installed via doom.
It seems doom installs packages from melpa rather than melpa.stable(?), so I'm using a 0.8 snapshot release.
Expected behavior
When editing larger adoc code blocks, adoc-mode should be responsive enough to not impede usability.
Actual behavior
When editing larger code adoc blocks, keystroke lag is long enough to affect usability.
I find myself making edits I did not intend to make.
This is a recording of me holding down the
x
key:Steps to reproduce the problem
I noticed the problem when editing the etaoin user guide.
I grabbed one of the larger code blocks (which doesn't really seem that big to me) and saved it to
test.adoc
:I started trying to reproduce the issue using
eldev emacs
from the adoc-mode project root, but because:clojure-mode
org
...I opted to create a custom emacs initialization script
adoc-test.el
:I then launched emacs like so:
To feel the lag, nagivate inside the code block and start typing.
In the animated gif above, I held down the
x
key.Experiments
How does org mode do?
The adoc-mode block highlighting code is based on org mode's.
test.org
:Let's retry our test under in an org mode code block:
To me, this seems fine.
What if we disable adoc-mode syntax highlighting?
If I
(setq adoc-fontify-code-blocks-natively nil)
this should disable syntax highlighting.Let's retry our test.
Interesting that we still feel some stutter here. Much less than with syntax highlighting enabled, but still there.
What about adoc-mode melpa stable?
The current stable version of adoc-mode is 0.7.0, let's retry with that.
melpa
tostable.melpa
inadoc-test.el
rm -rf ~/emacs-packages-testing123
And then launch emacs as above,
emacs --no-init-file -load adoc-test.el
This feels fine to me.
Environment & Version information
Adoc-Mode version information
Version
20230413.800
Emacs version
28.2
Operating system
Pop!_OS 22.04
Hardware
iMac 2013, 32gb RAM, SSD drive.
Next Steps
I'm admittedly an emacs elisp neophyte, but am happy to take a stab at some ways to improve performance here, if possible.
I'm curious as to why org-mode code blocks seem to edit without noticeable lag.
Perhaps they've made tweaks over the years that we could pick up?
Or maybe adoc-mode is, by design, doing more work?
The text was updated successfully, but these errors were encountered: