Slow load times ~ 15 second for every project every time

[srevenant]

Thanks in advance for your bug report!

• [X] Have you reproduced issue in safe mode?
• [X] Have you used the debugging guide to try to resolve the issue?
• [X] Have you checked our FAQs to make sure your question isn't answered there?
• [X] Have you checked to make sure your issue does not already exist?
• [X] Have you checked you are on the latest release of Pulsar?

What happened?

Slow load times ~ 15 second for every project every time

Pulsar version

1.119

Which OS does this happen on?

🍎 macOS

OS details

Sonoma

Which CPU architecture are you running this on?

x86_64/AMD64

What steps are needed to reproduce this?

start projects. Discussed w/ @savetheclocktower

Additional Information:

No response

[savetheclocktower]

@srevenant sent me a profile of a window reload and I noticed this block in the middle:

That's Pulsar hitting NativeCompileCache each time a legacy Tree-sitter grammar is loaded, and taking between 300ms-700ms each time. This block represents 5.5 seconds where the UI is frozen to the user.

I can't find a similar block in my startup profile, even though @srevenant and I are both on Intel Macs running Sonoma. But I have seen this sort of slowdown in the past when I've run an unsigned version of Pulsar, such as one generated from a CI job.

I don't have a good understanding of what invalidates the compile cache (or if this is just a visible symptom of a problem elsewhere), but I might have to go spelunking through the Git history to understand more about NativeCompileCache and the problems it solves. (Here's where it was introduced.)

[AzzaAzza69]

I would say this appears to have been addressed as the GUI is no longer frozen after selecting load a project as of v1.123. Git still takes a fair while to appear in the right tab though...

[savetheclocktower]

I can't think of an explanation for why it would've suddenly gone away, but I'm glad.

As for the Git tab, I'm still at a loss. A profiling session might reveal the same underlying (mysterious) cause, or it might be something unrelated. Git, in particular, shells out a lot, so that's one possible cause of Git-related slowdowns — if there were an issue that made Node slower to spawn processes, then it would affect Git much more than other editor features.

[scooterlord]

Hello. I am having issues with slow load times as well.

14600k / 32gb DDR5 installed on PCIe 4x NVME Windows 11 Pro / brand new installation Version 1.123.20241201221 x64

Timecop indicaets the following - 9.6s 'Window load time'

Any suggestions or pointers on what I need to check?

[savetheclocktower]

@scooterlord Do you have any packages installed? If so, does the problem persist if you launch in safe mode?

[scooterlord]

@savetheclocktower thanks for getting back to me on this one. In safe mode, the window load time is 1563ms.

For packages, except the default ones I have the following community packages installed: ftp-remote-edit increment-me lorem random

Although I don't have a screenshot of those packages, it didn't take long for them to be loaded - like 200ms overall.

Now, after I ran in safemode, I closed it and run again, and now it loads in 1221ms - so it's fairly inconsistent. Up until the point I replied to this ticket, it was usual to take more than 7-8secs until it became responsive. Is there anything else I can investigate further?

[savetheclocktower]

Up until the point I replied to this ticket, it was usual to take more than 7-8secs until it became responsive. Is there anything else I can investigate further?

So you're saying that a normal launch now seems to be quicker? If so, that suggests you might've had a problem with cached window state, even though that doesn't seem to make sense (you mentioned this was a brand new installation).

If it starts happening again, try the following:

• Quit Pulsar
• Open a shell (cmd.exe or PowerShell) and navigate to your project directory
• Run pulsar . --clear-window-state

If that doesn't fix it, then do the dance you did this time — quit and relaunch in safe mode, then quit that and relaunch in normal mode. Then please comment on this ticket again and let me know what the resolution was.

If this comes back and the solutions above don't do anything, or if this happens often enough that the workarounds are annoying, you can run Pulsar from the command line with the --profile-startup flag. That starts the profiler early in the startup process; it should also open the developer tools so that you can stop the profiling session when startup is done, then save it to a file. If you choose to go that route, please comment on this ticket and attach that file. (I wouldn't blame you if you didn't feel like doing this.)

I don't have an explanation for why this happened this time or why it happens in the general case. In #892 we see a more traditional case of a very slow launch after an upgrade, and in those scenarios --clear-window-state seems to fix things because Pulsar is trying to restore window state as it was in an earlier version — and somehow that slows things down, possibly because it's incorrectly relying on a cache that should be invalidated. I must admit that there are certain parts of the infrastructure that we don't understand; they date back to the early Atom days.

The good news is that most of Atom’s development occurred in the open, so it's often just a matter of spelunking through Git/GitHub history to figure out why certain things are the way they are. I'm optimistic that we'll discover the root cause eventually; it's probably just a matter of investing the time.

[scooterlord]

So, here are the results of running the editor today.

Initial launch:

The following screen is after I loaded with pulsar . --clear-window-state:

However, during this command, I saw in the Terminal the following error, which seems to have looped until the editor finally launched:

I navigated to the error url but I don't understand the connection or how it affects pulsar.

[confused-Techie]

@scooterlord Thanks for the data in that last comment. But don't worry too much about that error message. There's likely several errors that appear due to non-context aware modules. It's just something deprecated by Electron that we are working on actively, so nothing we don't already know.

But very interesting how much it seems the window state effects your startup.

[scooterlord]

Hello again,

today it was way longer than usual - not really sure what bothers it because everything else on my computer opens instantly.. If there is anything else you can suggest I should investigate, let me know.

[savetheclocktower]

@scooterlord Have you tried any of the things I suggested in my previous comment?

Edit: I see you've tried --clear-window-state, so I'll suggest taking a startup profile via the --profile-startup flag. That's a bit of a pain, but it will give us pretty clear information on where the bottleneck is. Let us know if you need specific instructions.

[scooterlord]

@savetheclocktower Hello and happy new year!

Sorry it took me so long to respond. Here are the results of the --profile-startup command: