Remix.run Logo
dlcarrier 12 hours ago

Mostly the bloat. It's not just the order of magnitude more RAM and CPU usage than any reasonable editor uses, it's the lag that is really grating.

Yes, compiling can take time, that's reasonable. What isn't reasonable is for the user interface to be slower than I am. My computer can perform tens of billions of operations per second. When I click on something, there's no technical reason it couldn't respond in at least a 30/th of a second, if not a 60th. There's plenty of software that's been around for decades that can do this just fine.

nokturn 11 hours ago | parent [-]

Thanks for sharing! Noted! - performance

On a personal note, i totally understand, and I also feel frustrated when I have to wait for the machine, or when i start to feel the laptop getting warm on my lap. So to expand on this a little, would you say a 'monitor' with current CPU/RAM usage would be helpful to at least establish a relation between interactions / resource usage? For example, if you have a dozen worktrees nested inside your main repo and you open cursor, it will immediately jump to 400% CPU just from indexing all those files. Surfacing where this CPU usage is coming from could be a starting point?

mtmail 11 hours ago | parent [-]

One step back might be to figure out of the target use has dozens worktrees. I never used worktrees for example

nokturn 11 hours ago | parent [-]

worktrees are a must if you want to run parallel tasks in the same codebase... Either that or sandboxes :)

That example i gave above with the worktrees happened to me recently after a long time of not opening cursor - huge CPU usage and mbp fans immediately firing up. Didn't take long to understand what was happening, but still, no easy way for users to know if its indexing, extensions, or something else entirely.