Helm freezes ("select face" for "highlight-phrase")

[WorldsEndless]

This morning during my studies I was using highlight-phrase. Each time I used the command it became slower, until after about five times Helm effectively froze (I had to use C-g to escape). Other helm processes did not seem to be slowing down; M-x and C-x b were still full speed. The actual freezing occurred at the point where the command is preparing the list to ask what face you would like to use to highlight the phrase; it was fine the first time, then slower and slower until I could wait a full minute with no response. Killing all helm buffers did not effect it. Here is a profiler of the time, which shows 99% CPU usage on the funcall-interactively (use profiler-find on the .txt file):

http://www.toryanderson.com/files/profiler-helm-freeze.txt

Any ideas?

[tuhdo]

It did not occur for me with Emacs 24.4. Do you still ust workgroups2? Also, you should try in emacs-helm.sh to see if the problem still persists. If so, this will need to be fixed.

[WorldsEndless]

Yeah, I've disabled workgroups since our previous discussion. I've been able to reproduce this problem twice in helm.sh; the linked archive includes a recipe. It seems to occur at around 10 highlight commands, with un-highlight commands probably counting towards that if used (though I didn't bother with them in the latest recipe).

http://toryanderson.com/files/helm-freeze.zip

[thierryvolpiatto]

Tory S. Anderson notifications@github.com writes:

This morning during my studies I was using highlight-phrase. Each time
I used the command it became slower,

Try:

(add-to-list 'helm-completing-read-handlers-alist
'(highlight-phrase . helm-completing-read-symbols))

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[WorldsEndless]

@thierryvolpiatto that doesn't seem to help.

[thierryvolpiatto]

Tory S. Anderson notifications@github.com writes:

@thierryvolpiatto that doesn't seem to help.

So the problem should not be related to helm but maybe to font-lock or
something.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[thierryvolpiatto]

Looks like a emacs bug in the regexp used by hi-lock, I got a stack overflow error using it, but again not an helm bug, helm is in charge of completing the face to use to font-lock no more and if all cpu is used to font-lock previous regexps, helm become slow.
This happen generally when a regexp like e.g ".*" is used instead of "[^ ]*".

[michael-heerdegen]

Turning off helm-mode completely fixes the problem, so helm is involved.

Actually,

(add-to-list 'helm-completing-read-handlers-alist '(highlight-phrase . helm-completing-read-symbols))

helps for me, it reduces the delay significantly, though not completely.

I've recorded the backtrace frames from the debugger after having let debug-on-quit fire when the delay appeared. I'll send this backtrace to Thierry by mail because it's too large to paste it here. I see that in the source helm builds, the byte-code of the candidate-function is larger than 3 megabytes (!). I'm not yet sure why, but this is definitely not a font-lock thing.

[michael-heerdegen]

I can try to investigate further, but only if @thierryvolpiatto is interested in fixing.

[michael-heerdegen]

I tried to investigate.

The good news first: I've found a simple recipe from helm.sh:

(let* ((hi-lock-face-defaults
        '("hi-yellow"
          "hi-pink"
          "hi-green"
          "hi-blue"
          "hi-black-b"
          "hi-blue-b"
          "hi-red-b"
          "hi-green-b"
          "hi-black-hb"))
       (hi-lock--unused-faces hi-lock-face-defaults)
       (defaults hi-lock-face-defaults))
  (completing-read
   (format "Highlight using face (default %s): "
           (car defaults))
   obarray 'facep t nil 'face-name-history defaults))

Put it in scratch and eval with C-x C-e and hit G-g at the prompt. Do this again and again, a 15 times or so. The first time it willl be quite fast, but it seems to take twice the time as before at every attempt. Soon, it will take several seconds, etc.

The cause seems to be that

(length (all-completions "" obarray))

gets doubled at each call, though obarray doesn't get larger. At the end, "all-completions" returns nearly a million matches, though obarray has only 1511 entries.

The long completion list is what makes helm so slow. That "all-completions" returns so many "matches" makes no sense. Seems like a bug in Emacs.

Maybe I can find a recipe to reproduce the problem without helm.

[thierryvolpiatto]

Michael Heerdegen notifications@github.com writes:

I tried to investigate.

The good news first: I've found a simple recipe from helm.sh:

(let* ((hi-lock-face-defaults
'("hi-yellow"
"hi-pink"
"hi-green"
"hi-blue"
"hi-black-b"
"hi-blue-b"
"hi-red-b"
"hi-green-b"
"hi-black-hb"))
(hi-lock--unused-faces hi-lock-face-defaults)
(defaults hi-lock-face-defaults))
(completing-read
(format "Highlight using face (default %s): "
(car defaults))
obarray 'facep t nil 'face-name-history defaults))

Put it in scratch and eval with C-x C-e and hit G-g at the prompt. Do this again and again, a 15 times or so. The first time it willl be quite fast, but it seems to take twice the time as before at every
attempt. Soon, it will take several seconds, etc.

The cause seems to be that

(length (all-completions "" obarray))

gets doubled at each call, though obarray doesn't get larger. At the end, "all-completions" returns nearly a million matches, though obarray has only 1511 entries.

The long completion list is what makes helm so slow. That "all-completions" returns so many "matches" makes no sense. Seems like a bug in Emacs.

Maybe I can find a recipe to reproduce the problem without helm.

Thanks to investigate, I will not have access to a computer in the next
10 days or so, so I will not be able to help on this.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

Ok, have a nice time!

[michael-heerdegen]

Update: I found out that the growth of obarray happens when calling "helm-comp-read-get-candidates". Looks indeed like a bug in Emacs to me, since our code looks sane.

Here is the discussion in emacs-dev:

https://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00194.html

[michael-heerdegen]

Stefan Monnier has now commited a fix to master (i.e. Emacs 25) that should fix the issue: Commit 66ae3cf from April 15. It works for me.

[thierryvolpiatto]

Michael Heerdegen notifications@github.com writes:

Stefan Monnier has now commited a fix to master (i.e. Emacs 25) that
should fix the issue: Commit 66ae3cf from April 15. It works for me.

Great, thanks for your work on this.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997