-
Notifications
You must be signed in to change notification settings - Fork 344
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
Fontification is too inefficient #1177
Comments
@mrkkrp hi! Performance is my idea fix, I always want to make things faster. Recently, I have read few articles and increased GC threshold, byte-complied my .emacs and disables And about mentioned article, man, it's huge, I'd better make some contributions rather than wasting time to read it :D can you summarize? |
I recently found that although some recommend this, it's not a very good idea because the higher threshold you have the longer GC actually takes. With default setup GC is so fast that you won't actually notice while increased
Oh come on, I have no special experience with this. I'm sure that reading manual and some experimentation can give insights and it's certainly possible to hightlight Haskell syntax efficiently.
I'll first try to eliminate the need in Smartparens and figure out how to use Flyspell to check words that I type without activating
Well, basically it says that latency is bad. Even when you don't perceive it consciously, it can spoil your experience with editor. |
Yep, I've found similar precautions, but I didn't see any lags though I have quite performant hardware. For now I have threshold set to 100MiB
Oh, I really missing spell check in Emacs for ages and still haven't any chance to read something about this issue (I thought about spell checking last evening) :D Recently, my restless mind made to install NeoVim, Vim and read few articles comparing Atom and other editors/IDEs performance to Emacs, finally I've installed Emacs pretest version of Emacs 25 (namely 26.0.91.1), I have reinstalled all packages from MELPA and recompiled few other local packages I use, reconsidered to set scroll amount to 3 lines and disable linum mode, I noticed slight better performance comparing to Emacs 24. And there are a lot of small improvements here and there in Emacs 25 so now I can not wait its official stable release :D As for issue subject, I also have very limited time and believe so do most of us. Currently I would be glad to eliminate as much old issues as possible. Then we can concentrate on tokenizer improvements, I hope we will be able to have a robust, reliable tokenizer, which will help to improve and speed up such things as indentation (this will be huge win if we success) and fontifycation. |
@mrkkrp, the only part of efficiency that we have control over hides behind this line:
As you see we need some help getting more detailed information. As I see you are on a crusade for efficiency in a couple of Emacs packages. Will you create a package or at least a methodology to measure font-lock efficiency? That would be really good. |
Note also that it looks like this for me:
@mrkkrp: We need more help in reproducing this issue. |
Interesting. Did you try without any config or with some config? I tired with most part of my config enabled expept for Smartparens and Flyspell. Also note that it's not really important how much percents rendering funtion gets (well, from my experience), it's time spent in GC somehow correlates with typing experience. Anyway, it would be much more helpful if you posted full profiling report. |
Here you go:
|
Another run: CPU samples:
Bytes:
Code that tests produces those: (defvar the-test-counter 0)
(defvar the-test-buffer nil)
(defun insert-thing ()
(when (equal 0 the-test-counter)
(profiler-start 'cpu+mem))
(cl-incf the-test-counter)
(if (< the-test-counter 100)
(progn
(run-at-time 0.01 nil #'insert-thing)
(insert "x"))
(profiler-report)
(profiler-stop)))
(defun do-the-test ()
"Test font lock speed"
(interactive)
(setq the-test-counter 0)
(setq the-test-buffer (current-buffer))
(run-at-time 0.01 nil #'insert-thing)) |
59% of cycles spent in GC is not very good anyway. I don't really think this stuff is interesting read for |
Nonsense. Emacs GC is your average naïve mark-and-sweep, where collections take time proportional to the total heap size. The default While there's obviously a limit where increasing |
@Fanael, As with many things, I think it's about golden mean, which depends on your hardware. What I said is not something I made up, but my actual experience from tests I performed. Yes, default value is likely to be too small, and it's OK to increase it to 8 MB I think, but too big values can make situation worse. I also think that your argumentation would look even better without attacking people with “nonsense” claims. |
I find efficiency stuff very interesting and that is why I shared with both /r/haskell and /r/emacs. I suffer fontification sluggishness (or a similar problem) in org-mode and it annoys me to no end. We should not let |
This particular problem seems to be in your configuration only, so I'm closing this particular issue in favor of more general approach described in #1181. |
Haskell mode currently has inefficient fontification:
Try it yourself — set quite high frequency of key repeat on OS level and hold a key when is Haskell mode. You will see that dislay update is sporadic (well, of course you should turn off Smartparens and Flyspell, because they skyrocket typing latency). Compare with Emacs Lisp mode where characters appear continuously.
My understanding is that the higher time spent in GC the “slower” the experience. In Emacs lisp mode 5% of time is spent in GC even with aggressive indent enabled. Here we have 10 % and it turns out it's quite high already. In markdown mode it's 20% and it's unbearable (under certain conditions).
Why this matters? Typing with little latency in responsive editor is a joy. In Emacs, many packages use hooks that are executed after every key press (there are a number of them) plus some modes have inefficient fontification that actually makes “advanced” Emacs setup slower than some IDEs. It can get really slow. Web-based Atom text editor feels faster. In Haskell mode when everything sums up, it lags when I type fast.
Now I decided that I either switch to different text editor or make my Emacs as fast as it is when it's vanilla. I would really like to succeed in the latter.
And here is an article for you:
https://pavelfatin.com/typing-with-pleasure/
The text was updated successfully, but these errors were encountered: