4 ms·

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Here is one concrete example: visual studio

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Here is one concrete example: visual studio startup and debugging. Source: https://youtu.be/GC-0tCy4P1U https://youtu.be/GC-0tCy4P1U Maybe I could start collecting examples. I never did because it is so obvious. I mean, have you never updated android/iOS/windows on the same hardware? Regarding the "exactly" part in you sentence. Why would more features equal less performance? The only possible reason I can see this happening, is if you have features that run in parallel. Otherwise it's just another callback/if etc. That is, something to be triggered by the user that should have imperceptible impact (slightly more pressure on the instruction cache) on the performance of other features.

shuntress 5y ago
> Why would more features equal less performance? "More features" can include things that were not feasible in the '90s. Things that inherently consume more resources. Icons/images are a simple example. Of course good software can get plenty done with 16x16 images. Good software may get all that done and more with access to more memory for higher resolution images and more CPU cycles for image manipulation.
dahart 5y ago
> Why would more features equal less performance? […] Otherwise it's just another callback/if etc. Wait, really? Are you serious? Adding features historically is - by far - the single biggest cause of bloat and losing perf on a given fixed hardware configuration. I have no idea why you’re suggesting that unnamed “features” are “just another callback/if”. What features are you talking about, why are you assuming how they’re implemented? I don’t think Visual Studio is representative of most software, nor a reasonable demonstration of your argument above against clean code practices. That said, I’ve been using Visual Studio for 20 years, and in my experience it’s significantly faster now to start up than it used to be. The functionality has also changed, so it’s not an example of functionality staying the same while resource usage increases.
- fouric 5y ago
  > 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).
  - dahart 5y ago
    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.
cogman10 5y ago
Pretty reminiscent of Grace Hopper's nanosecond lecture [1] Certainly there are reasons why a feature might slow down a system beyond the branching (for example, if it requires you to load other resources)... but really, the issue is that as pointed out in the youtube video. Software companies very frequently do not care about performance. [1] https://www.youtube.com/watch?v=9eyFDBPk4Yw https://www.youtube.com/watch?v=9eyFDBPk4Yw

shuntress 5y ago

> Why would more features equal less performance? "More features" can include things that were not feasible in the '90s. Things that inherently consume more resources. Icons/images are a simple example. Of course good software can get plenty done with 16x16 images. Good software may get all that done and more with access to more memory for higher resolution images and more CPU cycles for image manipulation.

dahart 5y ago

> Why would more features equal less performance? […] Otherwise it's just another callback/if etc. Wait, really? Are you serious? Adding features historically is - by far - the single biggest cause of bloat and losing perf on a given fixed hardware configuration. I have no idea why you’re suggesting that unnamed “features” are “just another callback/if”. What features are you talking about, why are you assuming how they’re implemented? I don’t think Visual Studio is representative of most software, nor a reasonable demonstration of your argument above against clean code practices. That said, I’ve been using Visual Studio for 20 years, and in my experience it’s significantly faster now to start up than it used to be. The functionality has also changed, so it’s not an example of functionality staying the same while resource usage increases.

fouric 5y ago
> 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).
- dahart 5y ago
  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.

cogman10 5y ago

Pretty reminiscent of Grace Hopper's nanosecond lecture [1] Certainly there are reasons why a feature might slow down a system beyond the branching (for example, if it requires you to load other resources)... but really, the issue is that as pointed out in the youtube video. Software companies very frequently do not care about performance. [1] https://www.youtube.com/watch?v=9eyFDBPk4Yw https://www.youtube.com/watch?v=9eyFDBPk4Yw