Hi! The CJK support added in 7adc3b119fcb4ef58d3d077dc38bc974af8c584b seems to make evil-forward-word-begin run a lot slower than before. evil-backward-word-begin seems to be unaffected, speed wise.
On 2012-07-29, Nikolai Weibull <[email protected]> wrote:
The CJK support added in 7adc3b119fcb4ef58d3d077dc38bc974af8c584b seems to make evil-forward-word-begin run a lot slower than before. evil-backward-word-begin seems to be unaffected, speed wise.
Do you know a good way how to make this slow down apparent? I've just tested both function with the latest versions but cannot experience any difference. Maybe a certain file-type (major-mode) or old machine? Frank
On Mon, Jul 30, 2012 at 8:28 AM, Frank Fischer <[email protected]> wrote:
On 2012-07-29, Nikolai Weibull <[email protected]> wrote:
The CJK support added in 7adc3b119fcb4ef58d3d077dc38bc974af8c584b seems to make evil-forward-word-begin run a lot slower than before. evil-backward-word-begin seems to be unaffected, speed wise.
Do you know a good way how to make this slow down apparent? I've just tested both function with the latest versions but cannot experience any difference. Maybe a certain file-type (major-mode) or old machine?
I just hold down ‘w’ and let it auto-repeat. Did you try that? I ran with emacs -Q and load evil manually, with the same result (Fundamental mode). It’s not an old machine either (but I don’t think that’s relevant, as this command shouldn’t be slow on any sort of machine). I’ll investigate further to see if I can figure something out.
Am Tue, 31 Jul 2012 17:40:49 +0200 schrieb Nikolai Weibull <[email protected]>:
I just hold down ‘w’ and let it auto-repeat. Did you try that?
Yes, that's what I tried but apparently on a too powerful machine ...
I ran with emacs -Q and load evil manually, with the same result (Fundamental mode). It’s not an old machine either (but I don’t think that’s relevant, as this command shouldn’t be slow on any sort of machine).
Certainly you're right, it should be fast. I've just tried it again on my old notebook and there holding 'w' pressed shows a big slowdown (the cursor does not move at all until the button is released). The problem is that evil does a lot of cleanup work after each single command (usually in post-command-hooks, for example the repeat-system and cursor adjustment at the eol and eob). And this is partially relatively expensive (compared to a single forward-word) and probably be improved (IIRC there's a function `evil-adjust-cursor' that sometimes does some heavy stuff and it is called in forward word motions but not in the backward direction). Frank
On Tue, Jul 31, 2012 at 10:11 PM, Frank Fischer <[email protected]> wrote:
Am Tue, 31 Jul 2012 17:40:49 +0200 schrieb Nikolai Weibull <[email protected]>:
I just hold down ‘w’ and let it auto-repeat. Did you try that?
Yes, that's what I tried but apparently on a too powerful machine ...
Ah, so it was a question of computing power, after all.
I ran with emacs -Q and load evil manually, with the same result (Fundamental mode). It’s not an old machine either (but I don’t think that’s relevant, as this command shouldn’t be slow on any sort of machine).
Certainly you're right, it should be fast. I've just tried it again on my old notebook and there holding 'w' pressed shows a big slowdown (the cursor does not move at all until the button is released).
The problem is that evil does a lot of cleanup work after each single command (usually in post-command-hooks, for example the repeat-system and cursor adjustment at the eol and eob). And this is partially relatively expensive (compared to a single forward-word) and probably be improved (IIRC there's a function `evil-adjust-cursor' that sometimes does some heavy stuff and it is called in forward word motions but not in the backward direction).
I’m on a 2 GHz Intel Core 2 Duo. This work your talking about must somehow be shuffling around a lot of memory or something similarly expensive. Is the gap being moved? I mean, what can be so expensive? Is it the use of saved restrictions/excursions? It makes me sad when a text editor is slow in the year 2012 (on late year 2008 hardware). (I’m not blaming you, it’s just sad that this can even occur.) I guess the upshot is that it gives me added incentive to try to stop just holding down movement keys and instead use isearch or pressing “10w”.
You byte compiled Evil right? 'make' does it. On Tue, Jul 31, 2012 at 4:29 PM, Nikolai Weibull <[email protected]> wrote:
On Tue, Jul 31, 2012 at 10:11 PM, Frank Fischer <[email protected]> wrote:
Am Tue, 31 Jul 2012 17:40:49 +0200 schrieb Nikolai Weibull <[email protected]>:
I just hold down ‘w’ and let it auto-repeat. Did you try that?
Yes, that's what I tried but apparently on a too powerful machine ...
Ah, so it was a question of computing power, after all.
I ran with emacs -Q and load evil manually, with the same result (Fundamental mode). It’s not an old machine either (but I don’t think that’s relevant, as this command shouldn’t be slow on any sort of machine).
Certainly you're right, it should be fast. I've just tried it again on my old notebook and there holding 'w' pressed shows a big slowdown (the cursor does not move at all until the button is released).
The problem is that evil does a lot of cleanup work after each single command (usually in post-command-hooks, for example the repeat-system and cursor adjustment at the eol and eob). And this is partially relatively expensive (compared to a single forward-word) and probably be improved (IIRC there's a function `evil-adjust-cursor' that sometimes does some heavy stuff and it is called in forward word motions but not in the backward direction).
I’m on a 2 GHz Intel Core 2 Duo. This work your talking about must somehow be shuffling around a lot of memory or something similarly expensive. Is the gap being moved? I mean, what can be so expensive? Is it the use of saved restrictions/excursions?
It makes me sad when a text editor is slow in the year 2012 (on late year 2008 hardware). (I’m not blaming you, it’s just sad that this can even occur.)
I guess the upshot is that it gives me added incentive to try to stop just holding down movement keys and instead use isearch or pressing “10w”.
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On Tue, Jul 31, 2012 at 11:32 PM, Barry OReilly <[email protected]> wrote:
You byte compiled Evil right? 'make' does it.
Um, no? That seems to have solved it, though. Jeesh. Thanks! Still, it’s worked fine before without a byte-compiled version.
I'm having the same issue, with byte compiled evil. The funniest thing is how this issue is very unreliable: sometimes, when emacs was freshly start it works without problems and later after some work, it became quite sluggish. On other hand 'b' is still working without problems. Not sure is this related to similar issue, but after some time (when emacs is running in daemon mode) with couple of files and eshell, the whole editing experience became sluggish; could this be related to evil too, as I didn't catch the similar issue report on emacs list? Maybe some benchmarking against Viper mode (or automate it inside Makefile) can show weak points. From time to time I start viper for comparison, and always get amazed how responsive it is, no matter how many buffers or modes are opened. Regards, Sanel On Tue, Jul 31, 2012 at 11:32 PM, Barry OReilly <[email protected]> wrote:
You byte compiled Evil right? 'make' does it.
On Tue, Jul 31, 2012 at 4:29 PM, Nikolai Weibull <[email protected]> wrote:
On Tue, Jul 31, 2012 at 10:11 PM, Frank Fischer <[email protected]> wrote:
Am Tue, 31 Jul 2012 17:40:49 +0200 schrieb Nikolai Weibull <[email protected]>:
I just hold down ‘w’ and let it auto-repeat. Did you try that?
Yes, that's what I tried but apparently on a too powerful machine ...
Ah, so it was a question of computing power, after all.
I ran with emacs -Q and load evil manually, with the same result (Fundamental mode). It’s not an old machine either (but I don’t think that’s relevant, as this command shouldn’t be slow on any sort of machine).
Certainly you're right, it should be fast. I've just tried it again on my old notebook and there holding 'w' pressed shows a big slowdown (the cursor does not move at all until the button is released).
The problem is that evil does a lot of cleanup work after each single command (usually in post-command-hooks, for example the repeat-system and cursor adjustment at the eol and eob). And this is partially relatively expensive (compared to a single forward-word) and probably be improved (IIRC there's a function `evil-adjust-cursor' that sometimes does some heavy stuff and it is called in forward word motions but not in the backward direction).
I’m on a 2 GHz Intel Core 2 Duo. This work your talking about must somehow be shuffling around a lot of memory or something similarly expensive. Is the gap being moved? I mean, what can be so expensive? Is it the use of saved restrictions/excursions?
It makes me sad when a text editor is slow in the year 2012 (on late year 2008 hardware). (I’m not blaming you, it’s just sad that this can even occur.)
I guess the upshot is that it gives me added incentive to try to stop just holding down movement keys and instead use isearch or pressing “10w”.
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On 2012-07-31 22:11 +0200, Frank Fischer wrote:
The problem is that evil does a lot of cleanup work after each single command (usually in post-command-hooks, for example the repeat-system and cursor adjustment at the eol and eob).
Nikolai, could you test the above theory by evaluating the following forms in the *scratch* buffer? Does Emacs become snappier? Can you isolate it to one of the forms? (defun evil-repeat-pre-hook (&rest args)) (defun evil-repeat-post-hook (&rest args)) (defun evil-post-command-hook (&rest args)) (defun evil-refresh-cursor (&rest args)) Also, what is the output of "C-h v pre-command-hook" and "C-h v post-command-hook"? -- Vegard
On Wed, Aug 1, 2012 at 10:02 AM, Vegard Øye <[email protected]> wrote:
On 2012-07-31 22:11 +0200, Frank Fischer wrote:
The problem is that evil does a lot of cleanup work after each single command (usually in post-command-hooks, for example the repeat-system and cursor adjustment at the eol and eob).
Nikolai, could you test the above theory by evaluating the following forms in the *scratch* buffer? Does Emacs become snappier? Can you isolate it to one of the forms?
(defun evil-repeat-pre-hook (&rest args)) (defun evil-repeat-post-hook (&rest args)) (defun evil-post-command-hook (&rest args)) (defun evil-refresh-cursor (&rest args))
Only marginally. None of them have any drastic impact. I might not have made it clear before, but there’s a clear difference when running the version just before CJK support was added and running the version just after CJK support was added.
Also, what is the output of "C-h v pre-command-hook" and "C-h v post-command-hook"?
(evil-repeat-pre-hook) (global-font-lock-mode-check-buffers global-undo-tree-mode-check-buffers evil-mode-check-buffers evil-refresh-cursor evil-repeat-post-hook)
On 2012-08-01 10:23 +0200, Nikolai Weibull wrote:
I might not have made it clear before, but there’s a clear difference when running the version just before CJK support was added and running the version just after CJK support was added.
Okay, one more test, then. In the definition of `evil-move-word' in evil-commands.el, comment out the call to `evil-move-word-cjk'. Does this restore the old responsiveness? If so, then that's the function we need to optimize. -- Vegard
On Thu, Aug 2, 2012 at 9:57 AM, Vegard Øye <[email protected]> wrote:
On 2012-08-01 10:23 +0200, Nikolai Weibull wrote:
I might not have made it clear before, but there’s a clear difference when running the version just before CJK support was added and running the version just after CJK support was added.
Okay, one more test, then. In the definition of `evil-move-word' in evil-commands.el, comment out the call to `evil-move-word-cjk'. Does this restore the old responsiveness? If so, then that's the function we need to optimize.
Yes, that solved it.
Because `evil-move-word-cjk' seems to be problem, checking for character categories in the `word-boundary-p' macro (defined in evil-cjk.el) is probably too expensive (especially because the list of potential combining/separating categories is quite long). We can either try to improve its implementation or we could simply rely on Emacs built-in functions to do the work. For example, replacing `evil-move-word' as follows utilizes `forward-word' to do the whole work *and* respects character categories automatically: ====== (defun evil-forward-word (&optional count) (setq count (or count 1)) (let* ((dir (if (>= count 0) +1 -1)) (count (abs count))) (while (and (> count 0) (forward-word dir)) (setq count (1- count))) count)) (evil-define-union-move evil-move-word (count) "Move by words." ;(evil-move-word-cjk count) (evil-move-chars (evil-concat-charsets "^ \t\r\n" evil-word) count) ;(evil-move-chars "^ \t\r\n" count) (let ((word-separating-categories evil-cjk-word-separating-categories) (word-combining-categories evil-cjk-word-combining-categories)) (evil-forward-word count)) (evil-move-empty-lines count)) ====== (the function `evil-forward-word' is just a wrapper around `forward-word' to get the correct return value required by evil.) The good thing is that this approach is fast and also satisfies all test cases on my machine. The downside is that now `evil-word' is not used for the word motion anymore. But perhaps this is the right approach anyway. Emacs does already have a good definition of a "word" and corresponding movement functions, why should we invent another definition? I can even imagine to give non-word non-space characters their own category within evil, so the line (evil-move-chars (evil-concat-charsets "^ \t\r\n" evil-word) count) would not be necessary anymore (the word boundary between word and non-word characters would be defined solely by categories). If Emacs provides this mechanism, why not use it? Opinions, comments? Frank
I am the author of the CJK support and I agree with Frank's idea. The reason why I reimplemented `word-boundary-p' in Lisp is that I just didn't know a good way to use `forward-word' without breaking other behavior. Now, `evil-forward-word' is what I wanted to have. -- Lintaro INA mail: [email protected]
participants (6)
-
Barry OReilly -
Frank Fischer -
INA Lintaro -
Nikolai Weibull -
Sanel Zukan -
Vegard Øye