The only reason I switched to VS Code was speed.

[trusktr]

VS Code widows always started a lot faster. Atom's were painfully slow. Has or is this being addressed?

At the time, TypeScript IDE support was also better in VS Code, but all IDEs have caught up with the Language Server Protocol support.

But I loved basically everything else about Atom.

I would love to come back to Atom, but the speed was the only thing holding me back really.

If speed can be as fast or faster than VS Code, it could make a true resurgence.

[Daeraxa]

It will never be mega fast as but some of the upcoming changes are looking promising so far as performance is concerned. The Electron 21 update being a big one along with the WASM tree-sitter implementation.
Personally I've never had an issue with Atom (or Pulsar's) performance. I even run it on a really underpowered little ARM board and once it is running I can hardly fault its performance anywhere.

[trusktr]

Performance was fine out of the box, but the issue was that adding just a few plugins (nothing crazy, just things for basic language supports and improved UX like more UI for error reporting) would typically slow down Atom a lot.

In contrast, I add lots of plugins to VS Code (comparably for the same purposes, which is language supports, better error UX, and Git stuff) and it simply doesn't slow down much.

Maybe this is due to VS Code's very tight extension API? Extensions cannot do arbitrary things like inject DOM, or manipulate CSS. They have a limited and very specific JavaScript API that they must use (and this is probably why VS Code always looks so bland, because customization is restricted).

I don't really know the root cause, but after getting my Atom to spec for things I'd work on, startup time would get really slow. Runtime was fine though. Just startup time (new windows) was unbearable.

[savetheclocktower]

If you encounter this again, run the Timecop: View command and you'll get a breakdown of which packages are most responsible for a long startup time.

[meadowsys]

it simply doesn't slow down much

Hmm.. I wonder if this has to do with vscode (I think) loading UI first, and then deferring extension loading to later? so maybe it would be a perceived speed type of thing? Not saying you're wrong, but I do wonder if its actual speed or perceived speed ><

[idleberg]

If you encounter this again, run the Timecop: View command and you'll get a breakdown of which packages are most responsible for a long startup time.

For me, the largest chunks are two core packages: status-bar (500ms) and pulsar-updates (64ms). Both features that could easily be deferred or loaded asynchronously – the former even more so since an update check is not important at application start.

[mauricioszabo]

Pulsar starts a little bit slower than Atom. But performance overall is the same, or a bit better than Atom because of our recent Electron updates.

I'm curious on why loading up the editor faster is that desirable - honestly, I usually load my editor few times per day, so one second more or less is not an issue, but I've seen people honestly saying it's a deal breaker.

As for speed, Atom's and Pulsar's plug-in API is way more powerful than vscode, and this have the unfortunate side effect that a single plug-in can slow down or even freeze the editor. This is by design, and I don't see us changing this...

[trusktr]

I'm curious on why loading up the editor faster is that desirable

If your workflow involves opening and closing windows a lot, that's where the problem is.

I'm not the first to notice this though. Back when everyone was switching to VS Code, speed was always the praise. It's a real difference.

However, I'm coming back to try Pulsar now. It's been a couple years, maybe things have changed (at least computers are faster!).

[idleberg]

I'm curious on why loading up the editor faster is that desirable

Heard that before, from an Eclipse user. Yes, you can argue like that.

To me, the slow startup time is only an indicator that many things in Pulsar are not optimized for performance – it's the most noticeable thing.

[mauricioszabo]

Yes, Pulsar is not optimized for performance - that's indeed the case - if we had to choose between "be extensible" and "be fast" we would go for the first. But - we try to keep performance on acceptable levels too, and we're indeed trying to figure out how to speed up some noticeable problematic fronts (like the editor loading big files with long lines).

Just be in mind that fast load is a completely separated thing - sometimes it's even a trade-off (example: JIT languages and VMs trade loading the code faster to performing faster). There is a way to make Pulsar load faster but the documentation is scarce and it pokes too much on internals of the V8 and Chromium engines, things that we're not really familiar with.

[confused-Techie]

@trusktr I'll preface by saying I've never used VSCode. But as for startup times, if it helps here's what my startup times look like with Pulsar. Yes it might be a little bit slower than Atom was, but it's honestly not something that has ever caused me to think about it being slow.

But really for Pulsar to launch on Windows 10 (Pulsar V1.102.0) it takes Window load time: 1304ms (Window Load Time being the reported startup from the built in package timecop) so just over a second for the application to launch. And this is with all Core Plugins enabled, and with many community plugins installed. But I don't have any experience with VSCode to compare this to.

We do want to have better performance, but it hasn't been seen as the highest priority, until we get things updated.

[confused-Techie]

So I wanted to go ahead and provide a bit more detailed of an answer and went ahead and started testing the performance on my machine of Pulsar and VSCode and Sublime (For good measure). Just to help let you know what speed looks like if this is something you are willing to work with.

So a quick note, the startup time mentioned above, looks like it's only measuring part of the time within Pulsar, and is missing on some details. But otherwise lets get into my results.

The below values are all tested on my machine. Windows 10 22H2 (Ryzen 7 3800X, 32GB DDR4, GeForce RTX 2060), allowing each application ten total consecutive runs, waiting for the application to become fully rendered and interactible.

Sublime Text

Fresh Install
Build 4143

• Min: 0.0926s
• Max: 0.1238s
• Avg: 0.11263s

VSCode

Fresh Install
v1.75.1

• Min: 0.2784s
• Max: 0.3706s
• Avg: 0.30006

Pulsar

NOT A fresh install
24 Community Packages Installed, 80 Core Packages Installed
v1.102.0

• Min: 2.1696s
• Max: 2.3401s
• Avg: 2.24519s

---

So with the above said there is a measurable performance hit during Pulsars launch times. Although obviously it's something I've never quite noticed before, and maybe that says more about how I use my system, or how rarely I am waiting for the window to appear. But either way it's not the biggest issue for my workflow. And if it seems like it wouldn't be for you either we would be more than happy to have you aboard

[hanbing5210]

If the installation is not completely new (or if the software being tested uses the same plug-ins, including plug-ins that implement the same functions), the test results are of no reference

[meadowsys]

the test results are of no reference

The way I interpreted the results are if pulsar with many packages still only takes 2s to start up, that's 100% acceptable, at least for me. After all, what should matter the most is how efficient you are using a particular tool versus other tools. If the tool is the fastest thing in the world in terms of theoretical performance numbers, but you are slow to use it, at the end of the day you're still going to get less done. Plus, pulsar is far from laggy in regular use, which is a stat still not as important as your own efficiency using the tool (imho), but still much more important to the overall feel of a product's performance characteristics that startup time.

[ottok]

The benchmark above seems pointless as Pulsar - unlike the others - wasn't tested with a fresh install. Why not repeat it but run mv .pulsar .pulsar.bak first so that you get a clean install but can later return to your own install once done benchmarking?

[Crystal-RainSlide]

You may want to check out this Atom fork: https://thorium.rocks/atom-ng/

[mauricioszabo]

I tested it. Honestly, couldn't feel the difference.

What does make things faster is to update Electron, something we're in the process of doing; unfortunately (there's always a bad thing, right?) seems that in some systems WASM takes a hit, and we just migrated both tree-sitter and oniguruma to WASM (meaning - we get a performance boost for Node, but a hit for WASM, so syntax highlighting is about the same speed - we're not losing anything).

Thorium (Browser, Electron, and Atom) basically is adding some compiler flags to optimize the builds - that's all. Results vary, but in my system, even running the same benchmarks they did, I saw 2% performance improvements, at most...

[confused-Techie]

Also for Thorium I'll add, I checked it out a while back and they added some package's that seemed to add animated explicit content. Even visiting the repo GitHub warns you about the repo containing explicit content.

Checked it again, and seems to be removed? But still an odd choice, since it was added as a core package.

[Daeraxa]

The same dev had some drama over the same thing with their Chrome fork, lots of very questionable images hiding inside a browser... This was their recent statement on it https://alex313031.blogspot.com/2024/01/the-good-bad-and-ugly.html

[confused-Techie]

@Daeraxa Wow, so this is not only something weird for Atom, they developer consistently puts pornographic material in their projects. If memory serves, pretty sure one of the images was also labeled yiff in the Atom fork too.

[ottok]

I tested on my laptop with a fresh install, running pulsar $(mktemp -d) repeatedly. Timecop shows that typical window load time is 900ms. In package loading github and pulsar-updater both take almost 100 ms to load, probably because they call home and thus wait for a API response etc.

Opening dev tools (Ctrl+Shift+I) and hitting Ctrl+R or Ctrl+Shift+F5 (I am not sure what they do differently) I can see that fetching the tree-sitter.wasm consumes 900 ms, loading fonts 400 ms etc. The total window load time drops to 1.3 seconds due to the overhead the dev tools add. Screenshot below.

I am sure some of this could be optimized by people with deep JavaScript knowledge. Contributions welcome!

[savetheclocktower]

In the case of pulsar-updater, I'm a little surprised, because I don't think that the API request is even counting against its activation time as reported by Timecop. Nor do I think that the API request time is falling into any of the other buckets. The update check is initiated during activation, but that's an async function and activate doesn't return it, meaning Timecop has no way of keeping track of it. But if I'm right, that 78ms is a hell of an outlier, so maybe I'm wrong.

This is complicated, and Timecop deserves both credit and blame. Credit because it encourages packages to lower their activation time instead of performing costly work during startup. Blame because it's honestly pretty easy to juice the numbers; a package could make itself look better in Timecop without much effort simply by scheduling costly work to happen just after activation finishes.

But maybe this isn't cheating! When so many packages have to complete so many tasks, the only fair way to do it is to break your work up into jobs of considerate size, then schedule them to happen intermittently so that you don't have a big synchronous stop-the-world monopoly on the renderer process.

Unfortunately, lots of core tasks can't be deferred. Loading web-tree-sitter has to happen as early as possible or else we're delaying the moment that syntax highlighting first appears. I like when the editor feels fast to start up, but if I have to wait another ten seconds until I have a blinking cursor ready to apply highlighting to things I type, then the “savings” are illusory.

I spend 95% of my time in Pulsar running directly from source with the ATOM_DEV_RESOURCE_PATH environment variable set and the --dev flag enabled. I probably run the Reload Window command a few times an hour depending on what I'm working on. This is the equivalent of practicing free throws with an oversized basketball. When I grabbed the rolling release on Friday and felt what performance was like in a normal, loaded-from-bundle, non-dev mode, I felt like I was in a top-down Corvette on the first stage of OutRun.

I don't think I have a point… except to say that there's so much subjectivity around “speed” that it's hard to agree on any truths. I'm an elder millennial, so to me Atom/Pulsar isn't slow — Eclipse is slow. (You wanna stare at a splash screen for a while? Go try to run Eclipse from 2007.) Pulsar is slower than Notepad, but Notepad can't do snippets or symbol navigation or automatically renumber my Markdown lists. I think if people like the functionality, most won't mind waiting an extra fraction of a second.

[mauricioszabo]

For these numbers, the github package is indeed a problem: half the "loading" time of all core package is spent only on github (but that's a problem we were aware of, so nothing new here).

As for "lots of core tasks can't be deferred", that's basically what VSCode does - and honestly, I don't really like it. It loads the window faster, but then it takes a second or two to actually allow me to type things and open files. Some people like that approach, some don't (I don't) so there are always trade-offs...

[mauricioszabo]

Just for completion: I opened up my Ubuntu VM and capped my CPU to make it easier to compare loading times between Pulsar and VSCodium.

This is a deep-dive comparison between Pulsar (newest Electron branch, already with GitHub package and everything) and VSCodium. Both are on their latest (as of today) version, installed from their .deb files.

pulsar-loading.mp4

Yes, the VSCode UI is faster; the editor being "ready to use", no - both have roughly the same time to be ready. The final difference is - while VSCodium is "ready to use" a bit earlier (a couple milliseconds, really) it's not "fully loaded" - if you look at the top, and the bottom, elements of VSCodium you can see that it still populates some stuff after syntax highlighting is done, where in Pulsar, as soon as the editor is "ready to use" it's also "fully loaded".

[Crystal-RainSlide]

Asynchronous loading may not make the whole loading process a lot faster, but it sure make people feel like so, since all the basic stuff are loaded instantly and pop upon our eyes. This is worth considering.

[mauricioszabo]

Again, a matter of personal opinion. I hate this behavior, honestly - it's one of the things that infuriate me on Windows, for example, where after waiting 2s less to load than my Linux machine, I am presented with a desktop that's close to unusable for the next 10 or more seconds.

It's also not that easy on Pulsar, considering that most "core" stuff are plug-ins themselves so we need most of the API and other stuff to be loaded before we can display some UI.

EDIT: just to clarify, I'm not trying to be close-minded about a possibility of us loading Pulsar faster; just wanted to show my point, and by the way, if someone wants to try to speed-up Pulsar's loading process, we accept ideas/PRs/code fragments! In fact, I remember where Atom used the V8 Snapshots, it indeed loaded faster than it loads today - we just weren't able to make it work reliably when we switched Electron building and after we moved some dependencies...