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 <now <at> bitwi.se> 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 <frank-fischer <at> shadow-soft.de> wrote: > On 2012-07-29, Nikolai Weibull <now <at> bitwi.se> 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. _______________________________________________ implementations-list mailing list implementations-list <at> lists.ourproject.org https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Am Tue, 31 Jul 2012 17:40:49 +0200 schrieb Nikolai Weibull <now <at> bitwi.se>: > 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 _______________________________________________ implementations-list mailing list implementations-list <at> lists.ourproject.org https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list(Continue reading)
On Tue, Jul 31, 2012 at 10:11 PM, Frank Fischer <frank-fischer <at> shadow-soft.de> wrote: > Am Tue, 31 Jul 2012 17:40:49 +0200 > schrieb Nikolai Weibull <now <at> bitwi.se>: >> 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(Continue reading)
You byte compiled Evil right? 'make' does it.
On Tue, Jul 31, 2012 at 10:11 PM, Frank FischerAh, so it was a question of computing power, after all.
<frank-fischer <at> shadow-soft.de> wrote:
> Am Tue, 31 Jul 2012 17:40:49 +0200
> schrieb Nikolai Weibull <now <at> bitwi.se>:
>> 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’m on a 2 GHz Intel Core 2 Duo. This work your talking about must
>> 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).
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
implementations-list <at> lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
_______________________________________________ implementations-list mailing list implementations-list <at> lists.ourproject.org https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On Tue, Jul 31, 2012 at 11:32 PM, Barry OReilly <gundaetiapo <at> gmail.com> 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. _______________________________________________ implementations-list mailing list implementations-list <at> lists.ourproject.org https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
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 <gundaetiapo <at> gmail.com> wrote: > You byte compiled Evil right? 'make' does it. > > > > > On Tue, Jul 31, 2012 at 4:29 PM, Nikolai Weibull <now <at> bitwi.se> wrote: >> >> On Tue, Jul 31, 2012 at 10:11 PM, Frank Fischer >> <frank-fischer <at> shadow-soft.de> wrote: >> > Am Tue, 31 Jul 2012 17:40:49 +0200 >> > schrieb Nikolai Weibull <now <at> bitwi.se>: >> >> >> 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 >> implementations-list <at> lists.ourproject.org >> https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list > > > > _______________________________________________ > implementations-list mailing list > implementations-list <at> lists.ourproject.org > 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 <vegard_oye <at> hotmail.com> 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) _______________________________________________ implementations-list mailing list implementations-list <at> lists.ourproject.org https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
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 _______________________________________________ implementations-list mailing list implementations-list <at> lists.ourproject.org https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On Thu, Aug 2, 2012 at 9:57 AM, Vegard Øye <vegard_oye <at> hotmail.com> 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. _______________________________________________ implementations-list mailing list implementations-list <at> lists.ourproject.org https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
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: ina <at> kuis.kyoto-u.ac.jp
RSS Feed