[nh2]

I tried Zed last month but found that it uses high CPU usage even when idle (up to 50% of 1 core of my i7-7500U).

This is even higher CPU usage than my vscode causes.

Sublime does not do that; in fact it has 0% CPU usage when idle:

    sudo strace -fyp "$(pidof sublime_text)"

shows that Sublime issues no syscalls when idle, as it should be.

(Note, you need to either unfocus it so that the caret stops flashing, or switch from fading caret to fixed / non-fading caret, otherwise it necessarily has to do syscalls to draw itself.)

Zed spams syscalls even when its screen is entirely still:

    strace -fyp "$(pidof zed-editor)"

In fact Zed makes 800 syscalls per second when completely idle and unfocused.

[nh2]

Syscall spamming is one of the main reasons why computers get slow when many apps are running.

Good software does not do that; when idle, it should only consume RAM, not CPU.

Aside: Browsers, and Electron, seem to always syscall-spam no matter what, which is probably a key reason why people feel that all Electron apps bog down their computers. When your computer gets faster, the software just does more syscall loops per second, for unchanged misery.

[conartist6]

From what I recall they generally avoid caching anything and just try to repaint the whole UI really, really fast on every frame so I think that's the design.

It's like how a video game renders, which is their stated goal from the beginning.

I always thought their stated design goals were a bit... wonky.

[lstodd]

If you look into strace of something like IMGUI demo on say sdl2+opengl backend, you'll see about same syscall/sec number at 60 fps, but it'll all be sequences of writev, recvmsg, poll, clock_gettime and DRM_IOCTL_SYNCOBJ_ ioctls. Which is basically just polling for input and submitting gpu command buffers, nothing expensive, and nothing a cache can help with.

[nh2]

That does not really matter though: Even immediate-mode approach programs should just not be drawing new frames when the program logic says that there are no new inputs that can result in different pixels (e.g. no user inputs, animations, notifications, text content changes, etc.). One does not need to "poll" for input.

[lstodd]

> Even immediate-mode approach programs should just not be drawing new frames

They can't not. When the backend asks for a frame you give it a frame, or the result is not defined (a black rectangle instead of window content usually).

Even if you don't redraw anything at all it's still a 2d blit from gpu memory which is two triangles, a texture and sync object. Or you need to tell the window manager what's the window content this frame by any other way which also inevitably crossess process boundaries and thus is a bunch of syscalls. Plus you need to poll for input anyway.

edit: by "poll for input" I mean the literal poll() syscall. Which is ofc the basis of async and all. How else do you get to know there was any input?

[conartist6]

But a video game does!

You see why I think their logic that an IDE should work exactly like a video game does is not as strong as it sounds at first.

They claim browser engines just lack the raw speed to build an experience like Zed, but I know of no reason that it should be true.

[chromadon]

I've found that some of the language servers can really grind up a storm but Zed itself is usually pretty lightweight.

[nh2]

Can you repro my finding?

I'm running on a Zed with only 1 empty text file in it. So language servers should not be in use.

How do you measure "pretty lightweight"?

[frio]

I've always thought of it as lightweight, but checking it now, wow.