I wish people that made desktop apps would consider cpu and ram usage. "Oh I've just opened... ...let me index your vendor folder and check that I need to update at the same time whilst you only have 20% cpu left and 2GB of RAM remanding :D" no; fuck off. Why don't you wait until there's enough CPU power left to check for your update?

I understant why you want to wait for more ram - cuz it's a critical resource. But why wait for cpu usage to drop? What would you win? Definitely not time. What then?

I might say the same thing about frontend developers who use JS-based frameworks instead of server-side processing.

@netikras Responsiveness for one thing. You should be able to schedule the task as a background thread or something and the OS will take care of throttling it so it doesn’t take time away from higher-priority tasks like user interaction.

@devios1 But you still can't do anything with your IDE while it's indexing....... And after update you still have to restart the IDE. So in this case "responsiveness" would only give a false feeling of "things are working fast", bcz "things" will cost more time to complete.
when cpu-q is full, everything is proressing at optimal pace. When cpu-q < 100% - unused CPU time is wasted time.

I don't see the point in making IDE responsive to user interactions when at the end of tasks all the work environment will still have to be restarted :) Besides, HDD I/O does not interfere with NW I/O, especially when NICs have DMA

I'm not arguing. Just saying that I see no point here

@netikras Well we’ll have to disagree on that one. I think user interface responsiveness is far more important than how long it takes a background task like indexing to happen.

And what kind of an IDE can’t do anything until indexing completes? Isn’t indexing more of a pre-caching so that future operations are faster? Doesn’t your computer slowing right down or stalling while indexing kind of defeat that point?

@netikras Also it's not so much about the CPU utilization as it is about scheduling and priorities. If there is work queued, the CPU should ideally be at or around 100% utilization anyway.

What really matters is not hogging CPU time for background work away from user-initiated actions.

@devios1 With your latest comment I agree 100%. If there's some user iteraction than can be useful -- background tasks should not make the UI unresponsive. HOWEVER in JetBrains IDEs indexing is a core task running in background and its result is directly impacting UX. When indexing is complete (and only then) most of IDEs functionalities start working, like class/field/whatever mapping, autocomplete, search, etc. Before indexing is over IDE is as useful as a notepad app.

At least to me making indexing finish as quickly as possible makes a lot of sense, because making indexing finish ASAP == making IDE responsive ASAP. Thus burning CPUs at 100% seems to be the right thing to do.

@netikras "background tasks should not make the UI unresponsive."

Really that was the only point I was trying to make. Sadly it seems it's rarely the case. I just don't know if I should blame the OS or the app developers.

@netikras I think that CPU time and scheduling with regards to different parts of the OS (other userspace applications, kernel, init etc) is important, but yeah the individual applications shouldn't be responsible for that.. the kernel is. In terms of what an individual application itself is doing however, that's on the app. I don't want an app to be wasting time on indexing, synchronization or whatnot while it's in the foreground. There should be a clear separation between foreground and background time, and their priority in different states of the application. When the application is in the background, sync and things like that can take all the resources it gets from the kernel (which will likely be limited anyway). When the application is in the foreground, interaction should be prioritized, especially during UI transitions. And that internal prioritization is on the application to take care of.

@devios1 , @Condor that either means
- making IDE loading time (i.e. showing splash screen) _at least_ as long as indexing is running (which can easily be a matter of minutes)
- or forcing a user to use IDE without its core functionalities, which effectively means "yeah, use this fancy looking notepad. I'll show your project files and structure once you bring this IDE to the background so I can index all project data" :)

I mean... @Condor, when you login to a server which uses automounter to mount your homedir from NFS over vee-eeery slow internet. Do you prefer responsiveness, i.e. being dropped to /home/condor @sda1 immediatelly and then after 10 seconds be automatically dropped to /home/users/condor @some_nas? Or is it more convenient to wait those 10 seconds in a silent prompt until your homedir is found and mounted so you do not have to worry about your environment suddenly changing out of the blue (which could actually cause A LOT of serious problems).

@netikras personally I'd rather solve the problem in loading or mounting times at its source, instead of working around it.. slow internet connections with huge latencies aren't reliable enough to allow for network shares. Having to load an IDE with a bazillion features is something that I avoid for the same reason.. vim is *a lot* faster and does what I need it to. Perhaps the solution to unresponsive applications is by not having it do all that work to begin with. But for whatever's absolutely necessary and isn't absolutely required for core functionality, in background threads they go.

Maybe the issue we're discussing can be worded differently: why is the application that slow that it needs to be rescheduled to begin with? Is it in need of refactoring? Are the features that are loaded in as "core functionality" not excessive? What has to be kept, what can be discarded? Essentially optimization 101.

I get what you're all saying. My point was if I've opened vsc and phpstorm at the same time because I'm an idiot then I have about 380% of my cpu running for phpstorm's indexing and vsc's codehelper + window server running it doesn't exactly sound healthy after the fan kicks in. Obviously it can't be great. Especially seeing as I can't even close an application because they've both put put my system under strain. Suppose it's my fault really for being ill, tired and grumpy and opening both fucking applications and crashing the typescript server all at the same time.

Think I'm going to start learning how to use neovim and be done with these IDEs once and for all!!

I suppose the other annoyance I find is when an application/applications I've opened is hogging all the resources like that it's difficult to kill them off. Maybe I should remove all the shitty visual shit in my terminal window so that doesn't struggle to fucking open so I can kill some processes

Or like trying to read an article these days:

"Do you want to block notifications"

"You must agree to our third party permissions"

"We use cookies"

"Subscribe to our newsletter"

"You can skip this full page fucking advert in 30 seconds"

So irritating