bug#4771: 23.1; slow to interpret anthy maps

[Stefan Monnier]

>   $ time /usr/bin/emacs23 -q --eval '(progn (load-library "anthy") (load 
> "~/lib/emacs/anthy-el-my.el")(kill-emacs))'                                   
>  
>   real    0m8.293s
>   user    0m1.244s
>   sys     0m0.036s
>   $ time /usr/bin/emacs22 -q --eval '(progn (load-library "anthy") (load 
> "~/lib/emacs/anthy-el-my.el")(kill-emacs))'
>   real    0m1.197s
>   user    0m0.164s
>   sys     0m0.040s

AFAICT, anthy-el-my.el mostly calls functions which send some text to
a sub-process and then wait for an answer.  It appears from the above
measurement, then that a large part of the time is spent waiting (see
the difference between `real' time and `user' time).

In the current anthy.el I see the following core communication function:

(defun anthy-do-send-recv-command (cmd)
  (if (not anthy-agent-process)
      (anthy-check-agent))
  (let ((old-buffer (current-buffer)))
    (unwind-protect
        (progn
          (set-buffer anthy-working-buffer)
          (erase-buffer)
          (process-send-string anthy-agent-process cmd)
          (while (= (buffer-size) 0)
            (accept-process-output nil 0 anthy-accept-timeout))
          (read (buffer-string)))
      (set-buffer old-buffer))))

as well as the following initialization:

   (defvar anthy-accept-timeout 50)
   (if (string-match "^22\." emacs-version)
       (setq anthy-accept-timeout 1))

So could it simply be that accept-process-output always waits the
full timeout?  There are 152 calls to anthy-change-hiragana-map in
anthy-el-my.el.
So in Emacs-22 this would result in about 152 * 1ms = 152ms
of wasted waiting time (negligible) whereas with any other version you'd
get about 152 * 50ms = 7.5s of wasted waiting time.
So I think the problem is in anthy.el.


        Stefan