I probably have that many LoC between all the open files in VScode on an M1 and also love the performance. Only issue I've had so far is the Terraform Language Server running 18 threads at all times and grabbing too much CPU once or twice a month.

Yeah, I had the same issue with the terraform plugins, I honestly had to delete them. So far I haven't found an alternative but honestly I don't write that much terraform anymore.

It still a beta, so I think it can be acceptable BUT it is not tiny.

What I like about VSCode is that is slick and lean without plugins, and with remote support it is still "light"... And I was a huge Emacs, Emacs-org fan, so if I use VSCode because it gets the work done at the end of the day (TM)

I think, correct me if I am wrong, Fleet is written in Kotlin, hence running on top of JVM. ( I am assuming Kotlin Native not being used yet )

While I dont think VSCode is fast and lean when compared to Sublime or other Native Editor. It is well optimised.

I do wonder if Fleet could catch up or even exceed VSC in the performance / resources usage department.

It totally could, the JVM is really fast. JS interpreters are fast too these days. So I don't expect much difference between the two.

One department where the JVM may win is latency (the new GCs are incredibly fast so no impact there) for typing to display.

Other than that I don't expect much difference.

Fleet, like the other JetBrains IDEs is indeed running on the JVM.

It also has some components in Rust and a special GUI framework.

There is a great series of blog posts about its architecture and design here with a lot of details:

https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...

On my Linux, it barely consumes anything and opened 300k line code without a problem when VSCode crashed instead.

I guess the OS matters.

Linux here, opened a folder with less than 3k loc in all files combined. It is currently in the background (smart mode is disabled), FF in the foreground. KDE system monitor is reporting 3%-5% CPU usage and 946,272K of memory usage. Also, if I move the window, my mouse becomes sluggish for about a second afterwards.

By comparison, the exact same folder open in Sublime is using 789,236K of memory (most of which is likely cached from the indexer + LSP plugin which has accumulated over the past few days), and no CPU usage.

Obviously this is an early preview, so it's not a fair comparison at all. I'm really excited for this though, as it's certainly very promising right now.

I was experiencing similar performance problems on linux. Multiple cores pegged and multiple gb used while idling.

Well, I think NexGen Cloud IDE crowd gonna love it. From your review I take it as it is the next hot thing.

Sounds like there is initial setup going on in the background. I highly doubt it will keep the CPU at 100% at all times unless there is a severe bug.

calm down, it's a Preview release

and please lets not start with the Vim vs the World again

Did you get the Apple Silicon version? The default download for MacOS was Intel for me, had to click the drop down.

I opened a project with about 230k lines of Java code on my Intel Mac, it's idling around 800MB of real memory. Though I don't have Smart Mode on

While annoying, all intellij EAPs (early access previews) are very cpu intensive, as they run in debug mode by default to create diagnostics and crash reports. Kinda similar like if you would keep the debugger open in your browser. Not sure if you can disable it, but thats the main reason why I stopped using EAPs for work.

But the ram is typical intellij, they take what they can get from the OS :)

any source on that claim? I.e. that eap are cpu intensive?

I can't find a source to my claim. Just now downloaded webstorm 2022.2.3 stable and webstorm 2022.3 EAP to compare, but they seem to behave similar in cpu. Every now and then in the EAP in the activity monitor a "diagnostics dumper" pops up, but only for a brief moment. Maybe they improved it a lot. I remember complaining about EAP performance a long time ago and remembered an answer to expect a few more cpu usage from an EAP (the diff was not as stark as 100% though, it was more like 20% EAP vs 5% stable).

I mean please don't judge the CPU profile of an EAP to the final product.

I don't have a source other than that I develop plugins for IntelliJ professionally, but it's definitely true that performance is generally not a focus earlier in EAP cycles. I think they mention it when you download an EAP release.

> But the ram is typical intellij, they take what they can get from the OS :)

Aha, thanks! I was wondering about that (using CLion 2021.3 with Rust plugin with currently a tiny test project open, currently using 2.3 GiB RAM, puah)... .

Well, they cache many things to make code analysis fast, so they are one of the few softwares that do make good use of memory. Some older version had very low heap size set and that can cause slow downs, so 2+ GB is recommended at least in my experience.

i give intellij about 10GB to play with. i don't care. im not using it fot anything else. cache away. will happily trade ram for speed

> they take what they can get from the OS :

It's the opposite, they run in JVM so there's an upper bound at around -Xmx ("around" because you still have stack allocated and JNI allocated, but heap is usually the biggest pool of memory by a large margin)

on the flip side it also has a lower bound at -Xms

Personally I have mine running with 16/32G heap. It's my work computer not like I need the 64G ram for gaming :)

I haven’t experienced this with Fleet after using it some months.

However, from using the other JetBrains tools the performance killer for builds and indexing libraries and documentation has typically been slow file system access.

These IDE even warn you when they detect this. I don’t remember seeing this warning in the Fleet preview.

A common solution is to disable aggressive anti-virus scanning for you project folder and some key application folders so it does not slow down the build.

Another cause is slow remote mounted file systems that you might have if you are using VMs, WSL or Docker.

If I remember correctly the docs have detailed information about this.

JVM heap size is not Fleet's fault. You should be able to manually set it like Intellij.

A craftsman's work is always limited by the choice of his tools.

They could have built it in something different that doesn't require a huge footprint. It is inherently their fault since they chose the tools, but I definitely understand the pros they gain from it.