5 ms·

I've had people tell me all of the extra bloat/slowness in modern software is because it has more features, and because accessibility / localization is a thing

I've had people tell me all of the extra bloat/slowness in modern software is because it has more features, and because accessibility / localization is a thing more often. I'm not sure I actually believe that's true. Maybe accessibility and localization contributes to bloat/slowness, but that doesn't mean it couldn't be much much more efficient and keep the same features.

vardump 7y ago
Software is usually slow because most of the time developers don't get paid for runtime performance, but features.
Accujack 7y ago
Present day programs aren't optimized because they don't have to be. No one needs to gain a competitive advantage by squeezing the last bit of performance out of hardware because for a long time we've had steadily increasing performance levels and backward compatibility. Applications which need more performance than the present level of hardware can deliver so badly that they need to optimize to that level are very rare. That's why Windows is the size it is nowadays... it's optimized for delivering the same user experience on all hardware, compatibility, language flexibility, manageability and user friendliness (don't laugh) instead of performance. It essentially performs the same function that Windows 3.1 did, but it does it on a far greater variety of hardware running a far larger assortment of software. It's bigger and slower than it could be, but there are always trade-offs, and Microsoft hasn't really had any competition in operating systems for decades... Linux and variants have their place, but it's not on the desktop for most people, at least at the moment.
- slowhand09 7y ago
  I would disagree with the "they don't need to be" stmt. Many photographers and artist have legit gripes in the lengthy time many filters and transforms take in post processing. Many of these are recipes that are applied en-masse to all files in a directory.
  - Accujack 7y ago
    Well, I was obviously generalizing, not stating that no programs anywhere need to run faster. However, taking your example, the filters can't really be optimized because they're applications run on top of a bloated operating system which isn't optimized for the reasons I mentioned. Writing a highly optimized program to run directly on the hardware of a given machine would speed up filters tremendously but also be a trade-off in terms of manageability.
- codesushi42 7y ago
  I disagree. Software nowadays is atrocious because it's not optimized. It's just that average users have become more accepting of long load times and bloat. Here's an example. In the mid to late 90s, gamers would complain a lot about load times for CD ROM games. For some gamers, the load times were a deal breaker. This was one reason Nintendo could get away with using cartridges on the N64. Fast forward to the present, and load times for many mainstream games is FAR worse than the 1-2x speed CD based consoles of the 90s. And a lot of this is due to sloppy, unoptimized code, e.g. loading assets. And yet no one bats an eye. Another example is the web. There are so many garbage, unoptimized sites that load on my smartphone as if I were on dial up (I'm looking at you, Gawker). Yes, those pages contain a lot more multimedia content nowadays, but they still load at the same rate as a typical page in the 90s would have on dial up. And with Moore's Law now ending (ended?), optimization may come back in vogue.
  - bitwize 7y ago
    The N64 lost its console generation and solidified Sony as the market leader, in part because it used cartridges while everyone else used CD-ROMs. Way to choose an example that disproves the very point you were trying to make. As for load times today, most modern games are implemented as scripts and assets for one of the big engines, usually Unreal or Unity. It's hard enough to manage all the assets that go into a modern game; an optimized loader would just make wrangling them all even more difficult.
    - codesushi42 7y ago
      The N64 lost its console generation and solidified Sony as the market leader, in part because it used cartridges while everyone else used CD-ROMs. Way to choose an example that disproves the very point you were trying to make. Yes, I realize that. But the point was that poor decision was not enough to kill it, and the N64 was still a commercial success. A lot of gamers even preferred cartridges back then because of they didn't require load time. As for load times today, most modern games are implemented as scripts and assets for one of the big engines, usually Unreal or Unity. It's hard enough to manage all the assets that go into a modern game; an optimized loader would just make wrangling them all even more difficult. That's not a real reason to not optimize.
- pjmlp 7y ago
  FOSS devs embracing Electron also does wonders for user expectations.
tombert 7y ago
I think people undersell the value of safety. Back in the 80's and 90's, it wasn't uncommon to drop into assembly to grab every last cycle of performance, since computers were so slow. We also didn't do garbage collection, and people were writing in languages like C and C++. Software from then was also prone to random crashes and freezes, which doesn't happen so much anymore. We've started to come around with languages like Rust, but a lot of engineers have (in my opinion rightly) come to the conclusion that it's better to abuse the faster speed of computers to have a higher assurance of the software being correct. Could I conceivably get better performance if I wrote something in C and wrote a custom allocator? Maybe, but I'd probably make a mistake, and my GC'd language is fast enough for most of what I do.
- hgoel 7y ago
  One can have safety without the absurd bloat though.
  - tombert 7y ago
    I agree with you in theory (hence why I gave a nod to Rust), but I think it's easier to have safe, bloated software. I think newer languages like Rust and Swift definitely are demonstrating the ability to have lean software that is just as fast as something written in C, but these are still relatively new in the scope of things. Much as I think Java is a garbage language, there's no doubt that, by default, it's safer than a program written in C. It also typically is bigger, requiring a bit more RAM and resources.
    - pjmlp 7y ago
      Check DoD's security report about Multics and how it avoids typical UNIX exploits thanks to PL/I instead of C.
- pjmlp 7y ago
  Back in those days some of us were actually using compilers for Pascal dialects, Basic dialects, with C and C++ being yet another set of languages. Then C++ started to gain market share on OS/2, Windows, BeOS, Epoch, macOS, Newton as the way to write UIs, even if their kernels and low level APIs were written in C, or C with C++ compiler style. All C++ libraries bundled with compilers, provided strings and vector types with bounds checking. It was the rise of C's adoption thanks to FOSS that brought the unsafety wrath upon us.
vanderZwan 7y ago
Sites that actually really care about accessibility, like gov.uk, seem to disprove the performance claim at least
nothis 7y ago
The numbers don’t really add up. Computers are a hundred times (replace with actual value, but it should work even for a 10x increase) faster, yet the feature set hasn’t increased by anywhere near that factor. Also “feature” is a big word, usually a single feature doesn’t even eat up that much performance. I think it’s rather — just as Moore’s Law — a psychological phenomenon rather than a mathematical one. There’s just so many seconds we’re willing to wait and at one point, we don’t even care. Also the Internet hardened us for long wait/download times.
- codesushi42 7y ago
  Exactly this. Anyone who was gaming and "websurfing" back in the 90s will recognize that load times today are no better than back then, and are often times much worse. And that view isn't a psychological rewrite of the past. I regularly game on systems from both the 90s and modern day, and the load times for modern games are usually much worse than the CD games of old. The funny thing is that people would complain like crazy about CD load times back then, even citing it as a reason why CDs could never become mainstream. And yet, here we are present day with obscenely shitty load times for most software. I think the one area that has improved dramatically has been video streaming though. Real Player and the like were terrible even for their time.
  - grawprog 7y ago
    >that load times today are no better than back then, and are often times much worse. Uhhhh, well I don't tend to wait 3-5 minutes for a single .jpeg to load on a website any more. I can stream a hq video in real time over the internet, whereas downloading a single 30MB realmedia video so pixelated you could barely see what was on the screen would take an hour or more to download. A 3MB mp3 would take 5-10 minutes. There have been massive speed increases in web surfing for sure. I don't understand how anyone that used the web back then could think otherwise. As for software load speed, the amount of data being loaded off a CD for a 2d or older 3d game is magnitudes smaller than the data being loaded from modern games. How many gigabytes of high res textures did those old games used to load? How many uncompressed HQ sound effects and music tracks? I remember installing multi-CD games and waiting and waiting,.then swapping the disc, then waiting then waiting, then back to disc one, more waiting, now disc 3. I'm not saying those things are better, but there's no way in hell my old 486 could have loaded multiple gigabytes of data at the same speed my laptop or even my phone now does.
mumblemumble 7y ago
> I've had people tell me all of the extra bloat/slowness in modern software is because it has more features Lately I've been making something of a hobby of replacing big scale-out Apache Spark ETL jobs with stuff that was hand-coded to use something other than Spark. Generally I'm finding that, with a little care, I can get a lot of these jobs done in less time on a single machine than I can running it on the Spark cluster. (Using code that's easier to reason about, too.) And even when I can't, I'm not sure it's enough slower to warrant the use of the cluster, on the principle that using half a rack worth of compute resources to get the job done in 45 minutes when you could do it in 60 on a single box isn't really a good tradeoff. All that long-windedness by way of saying, these big data tools are kind of slow and bloated. They're slow and bloated precisely because they have more features. All the extra work they need to do to achieve reliability when you're scaling out has a cost. But that doesn't necessarily mean that the cost is justifiable. A box truck is more capable for running errands than my Kia Soul, because I can fit half the grocery store in it. But I think we'd all agree that it would be an obscene waste of money to default to using a box truck to buy groceries and make Ikea runs, and justify that decision by pointing out that some small fraction of the time I'll need to transport more stuff than will fit in a Kia Soul, and it's better to standardize on a single model of car. In a computing setting, though, we do that sort of thing all the time.
- reddickulous 7y ago
  It's a lot easier to hire someone to drive a box truck than it is to hire someone to drive your Kia.
  - deleted 7y ago
    [deleted]

vardump 7y ago

Software is usually slow because most of the time developers don't get paid for runtime performance, but features.

Accujack 7y ago

Present day programs aren't optimized because they don't have to be. No one needs to gain a competitive advantage by squeezing the last bit of performance out of hardware because for a long time we've had steadily increasing performance levels and backward compatibility. Applications which need more performance than the present level of hardware can deliver so badly that they need to optimize to that level are very rare. That's why Windows is the size it is nowadays... it's optimized for delivering the same user experience on all hardware, compatibility, language flexibility, manageability and user friendliness (don't laugh) instead of performance. It essentially performs the same function that Windows 3.1 did, but it does it on a far greater variety of hardware running a far larger assortment of software. It's bigger and slower than it could be, but there are always trade-offs, and Microsoft hasn't really had any competition in operating systems for decades... Linux and variants have their place, but it's not on the desktop for most people, at least at the moment.

slowhand09 7y ago
I would disagree with the "they don't need to be" stmt. Many photographers and artist have legit gripes in the lengthy time many filters and transforms take in post processing. Many of these are recipes that are applied en-masse to all files in a directory.
- Accujack 7y ago
  Well, I was obviously generalizing, not stating that no programs anywhere need to run faster. However, taking your example, the filters can't really be optimized because they're applications run on top of a bloated operating system which isn't optimized for the reasons I mentioned. Writing a highly optimized program to run directly on the hardware of a given machine would speed up filters tremendously but also be a trade-off in terms of manageability.
codesushi42 7y ago
I disagree. Software nowadays is atrocious because it's not optimized. It's just that average users have become more accepting of long load times and bloat. Here's an example. In the mid to late 90s, gamers would complain a lot about load times for CD ROM games. For some gamers, the load times were a deal breaker. This was one reason Nintendo could get away with using cartridges on the N64. Fast forward to the present, and load times for many mainstream games is FAR worse than the 1-2x speed CD based consoles of the 90s. And a lot of this is due to sloppy, unoptimized code, e.g. loading assets. And yet no one bats an eye. Another example is the web. There are so many garbage, unoptimized sites that load on my smartphone as if I were on dial up (I'm looking at you, Gawker). Yes, those pages contain a lot more multimedia content nowadays, but they still load at the same rate as a typical page in the 90s would have on dial up. And with Moore's Law now ending (ended?), optimization may come back in vogue.
- bitwize 7y ago
  The N64 lost its console generation and solidified Sony as the market leader, in part because it used cartridges while everyone else used CD-ROMs. Way to choose an example that disproves the very point you were trying to make. As for load times today, most modern games are implemented as scripts and assets for one of the big engines, usually Unreal or Unity. It's hard enough to manage all the assets that go into a modern game; an optimized loader would just make wrangling them all even more difficult.
  - codesushi42 7y ago
    The N64 lost its console generation and solidified Sony as the market leader, in part because it used cartridges while everyone else used CD-ROMs. Way to choose an example that disproves the very point you were trying to make. Yes, I realize that. But the point was that poor decision was not enough to kill it, and the N64 was still a commercial success. A lot of gamers even preferred cartridges back then because of they didn't require load time. As for load times today, most modern games are implemented as scripts and assets for one of the big engines, usually Unreal or Unity. It's hard enough to manage all the assets that go into a modern game; an optimized loader would just make wrangling them all even more difficult. That's not a real reason to not optimize.
pjmlp 7y ago
FOSS devs embracing Electron also does wonders for user expectations.

tombert 7y ago

I think people undersell the value of safety. Back in the 80's and 90's, it wasn't uncommon to drop into assembly to grab every last cycle of performance, since computers were so slow. We also didn't do garbage collection, and people were writing in languages like C and C++. Software from then was also prone to random crashes and freezes, which doesn't happen so much anymore. We've started to come around with languages like Rust, but a lot of engineers have (in my opinion rightly) come to the conclusion that it's better to abuse the faster speed of computers to have a higher assurance of the software being correct. Could I conceivably get better performance if I wrote something in C and wrote a custom allocator? Maybe, but I'd probably make a mistake, and my GC'd language is fast enough for most of what I do.

hgoel 7y ago
One can have safety without the absurd bloat though.
- tombert 7y ago
  I agree with you in theory (hence why I gave a nod to Rust), but I think it's easier to have safe, bloated software. I think newer languages like Rust and Swift definitely are demonstrating the ability to have lean software that is just as fast as something written in C, but these are still relatively new in the scope of things. Much as I think Java is a garbage language, there's no doubt that, by default, it's safer than a program written in C. It also typically is bigger, requiring a bit more RAM and resources.
  - pjmlp 7y ago
    Check DoD's security report about Multics and how it avoids typical UNIX exploits thanks to PL/I instead of C.
pjmlp 7y ago
Back in those days some of us were actually using compilers for Pascal dialects, Basic dialects, with C and C++ being yet another set of languages. Then C++ started to gain market share on OS/2, Windows, BeOS, Epoch, macOS, Newton as the way to write UIs, even if their kernels and low level APIs were written in C, or C with C++ compiler style. All C++ libraries bundled with compilers, provided strings and vector types with bounds checking. It was the rise of C's adoption thanks to FOSS that brought the unsafety wrath upon us.

vanderZwan 7y ago

Sites that actually really care about accessibility, like gov.uk, seem to disprove the performance claim at least

nothis 7y ago

The numbers don’t really add up. Computers are a hundred times (replace with actual value, but it should work even for a 10x increase) faster, yet the feature set hasn’t increased by anywhere near that factor. Also “feature” is a big word, usually a single feature doesn’t even eat up that much performance. I think it’s rather — just as Moore’s Law — a psychological phenomenon rather than a mathematical one. There’s just so many seconds we’re willing to wait and at one point, we don’t even care. Also the Internet hardened us for long wait/download times.

codesushi42 7y ago
Exactly this. Anyone who was gaming and "websurfing" back in the 90s will recognize that load times today are no better than back then, and are often times much worse. And that view isn't a psychological rewrite of the past. I regularly game on systems from both the 90s and modern day, and the load times for modern games are usually much worse than the CD games of old. The funny thing is that people would complain like crazy about CD load times back then, even citing it as a reason why CDs could never become mainstream. And yet, here we are present day with obscenely shitty load times for most software. I think the one area that has improved dramatically has been video streaming though. Real Player and the like were terrible even for their time.
- grawprog 7y ago
  >that load times today are no better than back then, and are often times much worse. Uhhhh, well I don't tend to wait 3-5 minutes for a single .jpeg to load on a website any more. I can stream a hq video in real time over the internet, whereas downloading a single 30MB realmedia video so pixelated you could barely see what was on the screen would take an hour or more to download. A 3MB mp3 would take 5-10 minutes. There have been massive speed increases in web surfing for sure. I don't understand how anyone that used the web back then could think otherwise. As for software load speed, the amount of data being loaded off a CD for a 2d or older 3d game is magnitudes smaller than the data being loaded from modern games. How many gigabytes of high res textures did those old games used to load? How many uncompressed HQ sound effects and music tracks? I remember installing multi-CD games and waiting and waiting,.then swapping the disc, then waiting then waiting, then back to disc one, more waiting, now disc 3. I'm not saying those things are better, but there's no way in hell my old 486 could have loaded multiple gigabytes of data at the same speed my laptop or even my phone now does.

mumblemumble 7y ago

> I've had people tell me all of the extra bloat/slowness in modern software is because it has more features Lately I've been making something of a hobby of replacing big scale-out Apache Spark ETL jobs with stuff that was hand-coded to use something other than Spark. Generally I'm finding that, with a little care, I can get a lot of these jobs done in less time on a single machine than I can running it on the Spark cluster. (Using code that's easier to reason about, too.) And even when I can't, I'm not sure it's enough slower to warrant the use of the cluster, on the principle that using half a rack worth of compute resources to get the job done in 45 minutes when you could do it in 60 on a single box isn't really a good tradeoff. All that long-windedness by way of saying, these big data tools are kind of slow and bloated. They're slow and bloated precisely because they have more features. All the extra work they need to do to achieve reliability when you're scaling out has a cost. But that doesn't necessarily mean that the cost is justifiable. A box truck is more capable for running errands than my Kia Soul, because I can fit half the grocery store in it. But I think we'd all agree that it would be an obscene waste of money to default to using a box truck to buy groceries and make Ikea runs, and justify that decision by pointing out that some small fraction of the time I'll need to transport more stuff than will fit in a Kia Soul, and it's better to standardize on a single model of car. In a computing setting, though, we do that sort of thing all the time.

reddickulous 7y ago
It's a lot easier to hire someone to drive a box truck than it is to hire someone to drive your Kia.
- deleted 7y ago
  [deleted]