Question : Things seem to be a bit slow initially when opening up project folders; fine after initial open

[sortofsleepy]

Hello!

First off, apologies if this is technically answered already; I took a look through the readme first and after trying some things that looked like they might be a solution (mostly related to Git since it seemed like a potential culprit and I'm gonna be using an external client anyways) I'm here with questions.

• Basically the issue is that for some projects, the initial open of a folder can be noticeably slow, roughly 1-2ish seconds.
• After initially opening things, then things are fine and I can open things lightning quick.
• It's seems to really only happen in the parent/root folder, any subfolders seem to open fine.
• Based on the behavior, it feels like there's some kind of indexing going on. In addition, as soon as I start to open a folder I know will trigger a slowdown, I can see CPU usage spike in the Emacs process. However, ultimately I'm not certain if that's the situation.
• I have noticed that certain types of projects are perfectly fine
  • With my.emacs.d folder in Treemacs, no issues whatsoever.
  • With a more complicated project like a website, things slow down, even for simple single-page ones

Any ideas? At the end of the day it's not the end of the world if this is expected behavior but if things could be tweaked to be just a bit faster, that'd be fantastic.

In case it helps

• Windows 11
• version should be whatever was most recent on melpa, etc git(?) (pulled using straight.el) around 2.7.24
• Emacs is just the standard download from GNU; not native-comp enabled; v 29.2
• I have tried running the Emacs profiler but it doesn't seem to pick anything up that I can directly attribute to Treemacs
• I'm a little new to Emacs configuring so I just grabbed the default config snippit from the readme and tweaked from there. I did try it with no changes initially which is where I noticed the slowness.
• I've notice that if a Emacs is closed when a "slow" folder is already open, project navigation seems fine until I highlight the "slow" folder again
• I have tried from a completely barebones init file with Treemacs being the sole package being installed.

Thanks! 🍻

EDIT - just stumbled on something kinda weird

I hadn't thought much of it initially but out of curiosity, is there any significance to naming a folder in a project src?

• I noticed that src apparently gets an individualized icon compared to the other folders. I'm not sure where it's coming from, I have all-the-icons and treemacs-icons-dired installed.
• If I move the files inside src into another folder, let's call it app, and then delete src, everything is totally fine. There's no slowdown, files open very quickly.
• app is not given it's own icon.

[sortofsleepy]

Apologies for the adding a bump for a non-urgent issue - I figured out how to work around this for the time being and figured it might be more helpful to separate my findings into a new comment vs just editing the first one.

tldr' - rolling back to commit 56691a530abb61564c8df0456a18ff0f301c2055 gives me a noticeable improvement in speed. The problem is pretty much gone and things are MUCH better.

Anyways, a quick backstory, I started using Emacs again in the new year and started with Doom Emacs. After going back temporarily to Doom while trying to figure out what was happening, I noticed it was operating like I would hope, opening any project, any folder seemed really fast.

At the time I started using Doom; they had pinned commit 56691a530abb61564c8df0456a18ff0f301c2055. I figured out how to roll back my custom config to that commit and I appear to have no more issues.

Of course, it's just a workaround but hopefully that might offer clues as to what the issue might be with newer versions, assuming things aren't behaving as expected.

Thanks again!

[Alexander-Miller]

I hadn't thought much of it initially but out of curiosity, is there any significance to naming a folder in a project src?

JVM conventions. Professionally I use Kotlin most of the time, where your source code goes into /src/main/kotlin. Elisp build tools are too primitive to bother with something like real packages, but given the size of the treemacs repo it beats putting every file at the top level, or even everything into one file.

That is also the reason src has its own icon, it's a special name that many projects will have by convention.

rolling back to commit 56691a530abb61564c8df0456a18ff0f301c2055 gives me a noticeable improvement in speed. The problem is pretty much gone and things are MUCH better.

That's pretty close to 01a3bcd, which introduced custom directory icons. By itself that change should be harmless. In practice it's just minor changes to give directories their own icon lookup table no different than files.

There's been some initial trouble because the new icons were svgs and some people had trouble with rendering them, but they're all back to being pngs now.

You can try a few things:

Update to the latest version if you haven't already to make sure you're not using svgs.

Remove the src icon outright.

(ht-set! (treemacs-theme->gui-icons treemacs--current-theme) "src-open" nil)
(ht-set! (treemacs-theme->gui-icons treemacs--current-theme) "src-closed" nil)

Replace the icon with another

(ht-set! (treemacs-theme->gui-icons treemacs--current-theme) "src-open" (treemacs-get-icon-value "github-open"))
(ht-set! (treemacs-theme->gui-icons treemacs--current-theme) "src-closed" (treemacs-get-icon-value "github-closed"))

If you're using all-the-icons then all your icons are just fonts, so maybe changing inhibit-compacting-font-caches might help.

To test if the specific icon is to blame run this and then see if the buffer slows down too.

(dotimes (_ 100)
  (let ((i (treemacs-get-icon-value "src-closed")))
    (insert "\n" i i i i)))

[sortofsleepy]

JVM conventions. Professionally I use Kotlin most of the time, where your source code goes into /src/main/kotlin. Elisp build tools are too primitive to bother with something like real packages, but given the size of the treemacs repo it beats putting every file at the top level, or even everything into one file. That is also the reason src has its own icon, it's a special name that many projects will have by convention.

Ah got it. I wasn't sure if it was just a semantic reason or if there was something more to it since it seemed like it was the only folder affected.

Remove the src icon outright....

Looks like it was the icon. I removed the current one and replaced with the github icon and things are fine and fast. It does look a little weird now but I'll live(will probably look for another icon at some point).

Appreciate the quick response and ideas to try out!