> Wait, really? Are you serious?

It should be pretty obvious that many features should have no perceptible performance impact if they're not actively being used.

> Adding features historically is - by far - the single biggest cause of bloat and losing perf on a given fixed hardware configuration.

If by "bloat" you mean binary size - nobody is complaining about that. If by "bloat" you mean idle CPU, UI latency, startup time - that's an engineering failure.

> I have no idea why you’re suggesting that unnamed “features” are “just another callback/if”.

Because that's true. Most features literally have no reason to use CPU if they're not being used. If Spotify adds a new "double-shuffle playlist" option, there is no valid reason that feature should use any CPU except when it's actually being used to shuffle things.

> What features are you talking about,

Most features? Take almost any program, start enumerating the features, and then start partitioning them by what resources they consume while not in use. Let's see, Google Chrome, downloads tracker. Is there a good reason for it to use CPU while you're not clicking a download link? Nope.

> why are you assuming how they’re implemented?

This entire thing is about bad implementations. If a particular implementation of a computationally cheap thing is inefficient, then that's a bad implementation, and it should be rewritten. Nobody is complaining that ML models take a long time to train, or that videos take a lot of CPU to be transcoded, because everyone knows that those things are intrinsically computationally expensive, regardless of how you implement them (although obviously the difference between a good and bad implementation can still shave off massive amounts of time and space).

You're presuming to speak for @miltondts, while contradicting what they said. The argument at the top of the thread was that good implementations are to blame for perf decay.

> It should be pretty obvious that many features should have no perceptible performance impact if they're not actively being used.

That's true, and irrelevant. It's also true that feature bloat is the number one cause of software slowing down. It doesn't have to be all or most features, it's still a fact.

I've lost track of your point. Software is bigger? I agree. Some software is bloated and uses resources it doesn't really need? I agree. You're arguing with everything I say, but don't seem to be trying to have a conversation or to understand or give any benefit of the doubt. Some of the things you're saying are true, I may not be disagreeing with you, a lot of this is just not relevant to either my points or the comments I replied to.

> Google Chrome, downloads tracker. Is there a good reason for it to use CPU while you're not clicking a download link? Nope.

Did you mean to include during downloads to refresh the page, or during scrolling and interaction with the page? I don't understand your example, have you seen the tracker consuming copious CPU? Does this example support your argument about engineering failures somehow? I opened my Chrome task manager just now and my downloads tracker is consuming exactly 0 cycles. Have you seen Spotify shuffle consuming CPU? If not, why did you bring it up?

> Most features literally have no reason to use CPU if they're not being used.

This is completely meaningless, until you name all features and all software, and define what "feature" means in all cases. You have no basis here to make any claims about "most features" of software.

Many features do have reasons to use resources. Caching is a feature that always uses memory when not in use, and caching is absolutely ubiquitous. Rendering is a feature that uses CPU even when the user isn't asking for anything. Speculative downloads, background processes, pre-computation, event driven callbacks, timers... the list of things ("features") your OS and browsers and applications intentionally do when you're not looking is very, very long. Claiming otherwise only demonstrates ignorance of what's under the hood. Naming a couple of cherry-picked features that don't use a lot of resources is not particularly compelling.

> You're presuming to speak for @miltondts, while contradicting what they said.

I am presuming to speak for nobody except myself, by responding to your arguments.

> The argument at the top of the thread was that good implementations are to blame for perf decay.

I don't see that anywhere in the thread. If, by "good implementations", you mean "scalability, portability and clean code" - then you're wrong, because implementations that are highly inefficient are not "good", regardless if they're any of those other things too.

>> It should be pretty obvious that many features should have no perceptible performance impact if they're not actively being used.

> That's true, and irrelevant.

It's completely relevant, because the topic is "performance", and your argument is that the performance losses are caused by added features.

> It's also true that feature bloat is the number one cause of software slowing down. It doesn't have to be all or most features, it's still a fact.

...a claim which is so vague as to be unprovable, and for which you have provided absolutely no evidence whatsoever - so, no, it's not "still a fact".

Meanwhile, I can make any number of arguments from first principles as to why there's no good engineering reason why many of the added features of modern-day programs should cause the massive increase in used resources over their older equivalents.

I'm willing to bet that you cannot point out more than two or three features in Discord, Spotify, Teams, Atom, Slack, or other similarly bloated applications that actually necessitate their ridiculous resource consumption. As in, O(n) for space and time use. (hint: none of these programs are solving the traveling salesman problem)

> I've lost track of your point. Software is bigger? I agree. Some software is bloated and uses resources it doesn't really need? I agree.

Perhaps I should have stated my point more clearly: the main reason that modern programs are inefficient is because they're implemented with inefficient technologies, most relevantly Electron (and webtech more generally), and not because the added features that they bring are intrinsically computationally expensive.

> You're arguing with everything I say, but don't seem to be trying to have a conversation or to understand or give any benefit of the doubt.

A "debate" is different than a "conversation", and this isn't surprising. I'm not trying to have a conversation, I'm trying to debate points that you're making. Not everything can or should be a "conversation". Moreover, there's no "benefit of the doubt" to give - I'm not assuming that you're being malicious, I'm just asking for actual empirical evidence and/or argument from first principles - neither of which you're giving.

> Does this example support your argument about engineering failures somehow? I opened my Chrome task manager just now and my downloads tracker is consuming exactly 0 cycles. Have you seen Spotify shuffle consuming CPU? If not, why did you bring it up?

It should be pretty obvious that I brought those examples up to illustrate examples of features that should not use resources while not actively being used.

> Many features do have reasons to use resources. Caching is a feature that always uses memory when not in use, and caching is absolutely ubiquitous. Rendering is a feature that uses CPU even when the user isn't asking for anything. Speculative downloads, background processes, pre-computation, event driven callbacks, timers... the list of things ("features") your OS and browsers and applications intentionally do when you're not looking is very, very long.

None of these are "features" - these are all implementation details. A "feature" is the downloads page in Chrome, or the shuffle feature in Spotify.

> Naming a couple of cherry-picked features that don't use a lot of resources is not particularly compelling.

You haven't been able to name a single actual feature that has a technically valid reason to use significant resources simply by being added to a host program, let alone one that's relevant to the highly-inefficient applications that everyone throws around (Discord, Spotify, Teams, Atom, Slack). My features, while individual examples, are miles better than the literal nothing that you have provided.

And, for emphasis: I'm willing to bet that you cannot point out more than two or three features in Discord, Spotify, Teams, Atom, Slack, or other similarly bloated applications that actually necessitate their ridiculous resource consumption. As in, with big-O notation for space and time use. (hint: none of these programs are solving the traveling salesman problem)

> I'm not trying to have a conversation, I'm trying to debate

I can tell, please consider relaxing a little. I appreciate the time you put into responding to me, but FWIW your extra long reply is almost completely straw man from my point of view, and getting unnecessarily aggressive and hyperbolic now. I don’t need to debate this, because you’re not actually addressing my points, because you haven’t actually understood what I’ve said, because you’re trying so hard to debate. This conversation wouldn’t have gone down like this face to face, and as engineers there’s a pretty good change we’d agree. Good luck, TTFN.