How to diagnose an issue with slowness

[sturgman]

Hello all,

I am trying to diagnose an issue where helm responds slowly but I am having trouble making progress. If any one knows other ways to diagnose these, I would appreciate. Here is what I know so far.

1. Slowness happens only in an auctex buffer
2. It does not happens when point is after a closing curly brace, square bracket, or parenthesis
3. Slowness happens when I run kill-buffer, helm-M-x, and TeX-command-master but not when I run helm-find-files

I tried to run the profiler but I don't seem to bet getting any useful output from that. Any advise on how to dig through this?

Thanks in advance.

[thierryvolpiatto]

sturgman ***@***.***> writes:

Hello all, I am trying to diagnose an issue where helm responds slowly but I am having trouble making progress. If any one knows other ways to diagnose these, I would appreciate. Here is what I know so far. 1. Slowness happens only in an auctex buffer 2. It does not happens when point is after a closing curly brace, square bracket, or parenthesis

Can you tell what do you have exactly under point. Are you using the latest Helm?

…

-- Thierry

[sturgman]

I did more testing and this is what I observe:

a. No slowness:

b. Slowness:

So just text under point when I observe slowness.

[sturgman]

To your other question, I am using:
helm :: 20221117.1800 from Melpa
auctex :: 13.1.6 from Melpa

I'll check if there is an update and report back.

[sturgman]

Upgraded helm to 20221207.827 and still observe same behavior.

[sturgman]

I should say that I suspect there is something wrong with my overall config (although I have something pretty much identical in my other pc without problems) and not with helm itself. Mainly looking for advice on how to continue to troubleshoot. A question I have is whether there is something inherently different between helm-M-x and helm-find-files. Do these two commands operate in fundamentally different ways?

[thierryvolpiatto]

sturgman ***@***.***> writes:

To your other question, I am using: help :: 20221117.1800 from Melpa auctex :: 13.1.6 from Melpa I'll check if there is an update and report back.

Last commit is from 07/12/2022. I tried to reproduce and couldn't, I experiment no slowness here (from Emacs-28.2).

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[sturgman]

Alright. Thanks for looking into it.

[sturgman]

Just in case anyone else experience this. The problem has something to do with Windows and launching emacs as daemon from a shortcut link. I figured this out while bisecting my init file to see if any specific configuration was the issue (it was not).

So... if I launch runemacs --daemon from a windows link, I see the slowness. If I launch runemacs --daemon from a terminal window I see no slowness. Probably too niche an issue to diagnose further but wanted to document it here.

[thierryvolpiatto]

sturgman ***@***.***> writes:

Just in case anyone else experience this. The problem has something to do with Windows and launching emacs as daemon from a shortcut link. I figured this out while bisecting my init file to see if any specific configuration was the issue (it was not). So... if I launch runemacs --daemon from a windows link, I see the slowness. If I launch runemacs --daemon from a terminal window I see no slowness. Probably too niche an issue to diagnose further but wanted to document it here.

Thanks for this information, it will be useful for others. Unfortunately I can't reproduce as I have no Windows box to test on.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[thierryvolpiatto]

sturgman ***@***.***> writes:

I should say that I suspect there is something wrong with my overall config (although I have something pretty much identical in my other pc without problems) and not with helm itself. Mainly looking for advice on how to continue to troubleshoot. A question I have is whether there is something inherently different between helm-M-x and helm-find-files. Do these two commands operate in fundamentally different ways?

Not really, I am surprized this happen more with helm-M-x because this one doesn't look at what is at point whereas helm-find-files is looking to what is at point.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[guraltsev]

Actually, I am having the exact same issue here on windows and it seems unrelated to being launched as a daemon or as a normal instance. I posted on reddit since I did not know how to debug this.

[sturgman]

Mine is also unrelated to daemon or normal instance. It seems to be related on whether I launch the daemon from a windows shortcut or whether I launch it from a cmd instance

[sturgman]

The ones from a windows shortcut have the lags.

[sturgman]

I need to clarify. The daemon launched from cmd has the same issue. The one launched from an msys instance has no lag. So now I am thinking this has something to do with my environmental variables? Launching from msys perhaps changes something or sets some needed envvars?

[thierryvolpiatto]

Gennady Uraltsev ***@***.***> writes:

Actually, I am having the exact same issue here on windows and it seems unrelated to being launched as a daemon or as a normal instance. I posted on reddit since I did not know how to debug this.

Do you experiment this only from a tex buffer or everywhere once auctex has been loaded?

…

-- Thierry

[guraltsev]

Only in tex buffers (where auctex is activated automatically). I'll try to enable it in other buffers and see what happens

[thierryvolpiatto]

Gennady Uraltsev ***@***.***> writes:

Only in tex buffers (where auctex is activated automatically). I'll try to enable it in other buffers and see what happens

Could you try in a simple text-mode or fundamental-mode buffer with the same text you have at point in the tex buffer?

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[sturgman]

I have done this. If it is not in AucTex mode, the slow down is not seen. Same text is speedy in different modes.

[sturgman]

The slowdown happens when I have the MikTex installation in the path. I reproduce like this:
Slow down observed

• Keep MikTex in PATH
• Run runemacs -q --daemon
• Eval the basic helm configuration
• Navigate to Latex buffer.
• Feel the pain.

Slow down not observed

• Remove MikTex from PATH
• Run runemacs -q --daemon
• Eval the basic helm configuration.
• Navigate to Latex buffer.
• No pain but no Latex

A third experiment:

• Keep MikTex in PATH
• Run runemacs -q --daemon
• Navigate to Latex buffer.
• No pain but no helm :(

[sturgman]

Just discovered emacs-helm.sh. Using that configuration with MikTex in the path also very slow.

[sturgman]

I am giving up on helm for the time being, which is unfortunate. Testing Vertico and related compatible packages. No slow downs observed but a lot of my favorite features missing. I just spend too much time in AucTex and the slow down is significant.

[CloseToZero]

As shown in the above images, it's because ffap-latex-mode is slow, the reason it's it calls the external program kpsewhich by call-process. Comment out the expression (apply #'call-process ...) and reevaluate the (defun ffap-latex-mode ...), then helm-M-x will retain normal performance.

Unfortunately, I don't know enough related details to come out with a proper fix, but I wonder why helm-fuzzy-highlight-matches need to call helm-guess-filename-at-point even within the command helm-M-x which seems not related to filenames.

[sturgman]

Amazing find! I can confirm that this fixes the slow down. I have moved on from helm but this might bring me back! Thanks a lot! I recompiled ffap.el after modifying it and it works like a charm.

[CloseToZero]

Comment out (apply #'call-process ...) is not a proper fix, it's just a test to pin down the place of the problem.

Changing the condition (not (executable-find "kpsewhich")) to t may be a better temporary fix.

[thierryvolpiatto]

Zhexuan Chen ***@***.***> writes:

image image As shown in the above images, it's because ffap-latex-mode is slow, the reason it's it calls the external program kpsewhich by call-process. Comment out the expression (apply # 'call-process ...) and helm-M-x will retain normal performance.

Thanks to catch this.

Unfortunately, I don't know enough related details to come out with a fix, but I wonder why helm-fuzzy-highlight-matches need to call helm-guess-filename-at-point even within the command helm-M-x which seems not related to filenames.

helm-fuzzy-highlight-matches needs to know if the source called is completing file names or not. helm-guess-filename-at-point was one option to know this, unfortunately there is problems with ffap as always, so I have disabled this check.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry