I've been saying for a while now, that developers and their managers should use a low-spec machine, let's say the 5th-percentile of whatever their users are using in the field, at least one day a week. This might force some reprioritizing of performance and efficiency goals.
As long as devs spend their days with bugattis while writing software for corollas, this will continue to get worse.
The devs. They have the true power to do something about it. Basically, that way you tighten that iteration loop for optimal efficiency to nearly nothing.
Optimizing performance is very nontrivial and often means writing custom stuff, which will deeply affect TCO. It’s fine for devs to sympathize with users, but in the most ultimate perspective the users are actual or potential customers of the business and not your clients.
In other words, the business should have ultimate authority and responsibility to structure incentives and pursue priorities. Up until the engineer crosses over a boundary and becomes part of leadership.
I think it's the opposite. With exception to startups like Bun, it's big businesses that can marshall enough financial justification to do high-performance rewrites and maintain custom code.
A common complaint on HN is bloated web performance. Surely we don't think the web is bloated because of too much custom code as opposed to too many off-the-shelf components?
It may be non-trivial to dig yourself out of a performance hole if you didn’t account for performance at all in the design. The pervasive idea that you can make it fast later virtually never pans out.
In many cases, taking performance into account up front adds little overhead and won’t appreciably affect the design. But, if you codify some algorithmically inefficient approach into your public API, you’re going to find that hard to unwind. The engineering team should advocate for that when designing the product.
Nobody is saying hand-write it in assembly like RollerCoaster Tycoon so you can get decent performance on a 90MHz Pentium with 16MB of RAM.
Tons of software would run faster if it DIDN'T use custom stuff. Don't load a JavaScript framework for form validation if using `required` and `pattern` are enough. Don't write your own sorting algorithm unless it's faster than qsort(). Don't write your own data storage engine if SQLite covers your use case.
Story time: I once wrote a memset() replacement because one compiler kept optimizing out my memset() call and didn't have memset_s(). It slowed my program down a lot. When I looked carefully I saw I was always resetting the whole buffer, even though I was keeping track of how much had been written to it. Fixing that lead to a ~10x speedup (0.1s to process a large word processor document went to 0.01s, occasionally 0.02s).
That's an interesting example, probably most software products featured on HN are less complex then Rollercoaster Tycoon 1 in core logic, perhaps not in every aspect.
> Don't load a JavaScript framework for form validation if using `required` and `pattern` are enough. Don't write your own sorting algorithm unless it's faster than qsort(). Don't write your own data storage engine if SQLite covers your use case.
Most software is made by stitching together off-the-shelf components. I don't think people on the web need a warning about not writing too much custom code. The HN complaint about the web is regarding bloat from people who walk the mainstream road of web development. Loading a bloated framework to do whatever is an example of such mainstream development.
Yes, the slowness of my IDE will surely empower me to optimize... performance of rando enterprise internal website #25628 that I'm currently working on.
I hate this for developers. I got to experience this first hand because I had a boss who thought like you.
Developers generally need to run a bunch of resource intensive tools to build the application in the first place, so an underpowered system will already be choking. It means their app will feel slow no matter what. So then when they run it and it's slow, they will shrug and say it's just slow because their system is slow.
There might be a case for specifically running testing on a slower machine, though.
> It means their app will feel slow no matter what.
How so? Do the heavy tools need to run alongside the app? Are you thinking of something like Android emulator? For that scenario, keep the beastly workstation, but switch to a $150 phone.
I think its reasonable to say anyone evolved in the product should regularly use the end product on low end hardware. I wouldn't expect devs to run full development environments on low end hardware unless they themselves are building dev tools.
I think it's reasonable to have a separate machine to do building on. You can include a push to the target in the build script, or use network mounts or something. Remote debugging is a thing, if you need to use a debugger but don't have the resources to debug on the target. But I disagree with your basic assumption that
> It means their app will feel slow no matter what.
If you can make it feel fast or at least responsive on your underpowered machine, it should feel super fast on everything else. Even today's slowest machines can run some things fast. It does depend a bit on your market though; it might not be worth the effort, but there's a lot of applications out there that could use some speed.
Once you’ve got Node, docker, Postgres, redis, an IDE, etc running, the system is out of memory and already chugging before your actual app even opens.
It's massively easier to just give someone a macbook that actually works properly and runs everything you need than to hand out people plastic chromebooks and mess around with remote development environments. Then if required, hire some testers to click around on cheap hardware. But realistically, the users on 2010 laptops aren't the ones paying the companies bills so no one really wants to spend money on them.
Developers generally need to run a bunch of resource intensive tools to build the application in the first place, so an underpowered system will already be choking.
Straw man. Of course, if you crank that knob to the extreme bad things happen.
There might be a case for specifically running testing on a slower machine, though.
Agreed here. I think the optimal is for devs to be able to do intensive operations on a fast machine, dogfood for most of their time on a average machine, then test on a somewhat slow one.
Actually having to develop (browser, IDE, compilers, etc) on a slow machine is pointless torture, but I do see the value in the app that you're building running in a resource constrained VM or equivalent. That way your dev experience is crisp, but you get a more realistic sense of how your application functions for the end user.
Fully agree. Developers should regularly dog-food their software and they should have to do it on the lowest-spec machine/phone that the software claims to be supported on. Too many developers run their creations on their fully-maxxed-out development workstation beast machine, observe it runs fast enough, and call it a day.
It's a tremendous waste of money for a business to spend expensive developer time waiting on garbage workstations. Simply targeting benchmark/latency metrics is enough.
Precisely, but how well is that working out in practice?
Forcing them to CARE about targeting benchmark/latency metrics is the sticking point. And that requires shoving their face in it for long enough that it becomes unbearable.
Is there some way to reliably simulate this, e.g. using a VM? It would be nice to have IDE, build tools etc. using all available speed while running the output as if it was on slower hardware.
I've had better success with VMs for performance dogfooding in a desktop environment.
On mobile I've always gone back to testing on low end hardware, there are just too many inconsistencies when trying to simulate slower performance, outdated OS problems, touchscreen drivers, etc.
(second-hand information) Android was at a smoothness disadvantage vs iOS for a long time, because it was never an organization level priority for devices to scroll at >= 60hz without stuttering. Then some executives went "why is scrolling so bad on our phones but not on Apple's?" and suddenly it became a priority.
I remember before the priorities changed, some of their graphics programmers were very frustrated that they didn't have the freedom to invest in fixing it.
By the way... For anyone reading this wanting to solve exactly this problem...
This feature is currently part of devtools. But if it could be enabled as part of Chromes policy engine, then IT departments could enable it by default for all developers, managers, and everyone working on the product, specifically for only web URL's of the product itself.
So: If you want to help solve the fact computers are slow for everyone, probably one of the most impactful things you could do is to send a PR to the Chromium project to let the network and CPU slowdown code[1] be possible to activate from the policy code [2].
This may end up being a place where some of the newish ideas in IDEs can help.
You want the fast machine because you want the code-build-test cycle to be fast, but for immediacy reasons we want a little more hardware than we really need so that we don't get bogged down too badly in worst-case scenarios.
So when we run the software on the machine along side this behemoth, we may or may not see something comparable to the users.
And then we also like for interactions to go faster for us so that we can quickly get to the end of a thought without having to drop everything and fix the slowness first (also, too few of us actually know how to fix the slowness instead of papering over it).
As we lean into multiple machines, or at least virtual machines, I can see a sliver of hope here where we offload rather large chunks of the IDE to resources the application itself cannot 'see', due to partitioning, remote calls, or both. Things like running the language server elsewhere, or the application in a container.
I use a reasonably beefy machine to develop “heavy” desktop software. It’s definitely the kind discussed in this article. I find it frustrating that it has noticeable input lag even with moderate workloads for exactly the reasons mentioned.
But then you talk to end users and it turns out they work 80 hours on one big document with input lag of several seconds. Some actions can take 15 seconds. It’s mad. It’s larger than anything we imagined anyone to work on. It must be infuriating. And they don’t get beefier machines despite it being an instant cost saving. Because software is seen as magical anyway. They do in two days what would take 50 days to calculate by hand! That’s fast! So when you ask them what to prioritize surely they say “make it faster with heavy documents”?
No, they want more features. Because a feature can save then days or weeks or months. A faster program just saves them hours. So I sort of understand them (and why we build software that grows slow).
The problem is how we (devs) slowly but surely conditioned users (and even other, new coming devs) so that people don't even know how fast computers actually are and how crazy it is that those things are as slow as they are.
So when it comes to performance, people don't even know that things could (should?) be exponentially faster.
Imagine the first bank where a monthly job took a roomful of smoking people took four days complete with calculators. In comes IBM and says "we can sell you a machine that does this in five minutes". Sure it'll weigh a ton and cost a fortune, but you'll see it's worth it. So they buy it.
The machine performs half of 12 boring jobs at the bank needed every month. But there is still another half dozen jobs the IBM still cannot do. It doesn't have the punch cards. So the roomful of smokers does the rest of the jobs in a couple of weeks, ready just in time to start over with next months tasks.
Should IBM make the machine or its programs twice as fast, or have twice as many features, even if the programs are half as fast? They should double the amount of features. And double it again, and again, and again...
That's the whole problem:
With this local framing, it completely makes sense.
But it's exactly the same with fossil fuels:
Here and now, they are obvious choice with practically no downsides.
But scale those "close to nothing" downsides times 7billion people, 100k seconds in a day, 365 days a week.
And suddenly, the ammount of time and electricity alone wasted on something like, waitiing for windows explorer to start, adds to real world scales.
...But also, this implies that optimizing is inherently costly. Which is not always the case. Just the culutre of 'not caring' makes things go slower then they could, while still using the same high level languages etc.
Please go and do what you suggest for 8 hours a day then come back.
Giving bad tools to any professional is a bad idea for productivity. We have other ways of checking if software is slow.
It is all a question of company priorities as there are no professional standards whatsoever established. And companies ofc go for spend the least they can get away with.
In some big business companies this is solved by pre-installed "security software" that usually takes up about half of the RAM, sometimes even more, and is using a measurable chunk of CPU all the time.
I totally feel this comment, myself being a corporate drone that has to deal with this software.
Between disk encryption, anti virus, IT asset management, data custody tracking, etc; my PC is as slow as molasses.
Unfortunately I think its slow in a different way that low-spec machines are slow. Mine is very slow on IO ops, but I have 32GB of RAM and a 20-core i7, so plenty of resources available even after all the BS.
Yes and no. Businesses have cyber insurance policies. In a world of frequent ransomware attacks, many security policy changes have been mandated by insurance companies, and for legitimate reasons.
No its a mentality that has been in corporate for decades. The best way for IT to not get in trouble is to lock everything down and define strict policies that prevent any ambiguity and define peoples work requirements in strict categories. This used to be easier with the advent of timeshared terminals but the advent of desktop computing caught them off guard. Now they have done their best to seize back control so much so that it strangles companies to death(as faster moving startups don't have this problem and innovation at the big companies stall)
Well I am not joking. This has been their M.O. for as far as I can remember. It really sucks as I work for a company that is being strangled to death by IT locking down every opportunity for a developer to get anything done and countless meetings where nothing gets accomplished.
You're telling them that your convenience is worth more to the company than plugging a security hole.
The company can live with your loss of productivity because it is living with the loss of everyone's productivity. The company cannot live without security.
On top of that, if you are the only one making noise about slow computers and complaining about stuff and things then you eventually end up being the problem. I mean, why is that lone employee complaining so hard about wanting to remove security assurances from his machine?
or just get rid of microsoft in the workplace and enjoy the absence of a terrible environment with the addition of fewer attack scenarios, better software and happier users but sad management people, but they don't do work on their machines anyway ;)
We tried. Managemen and sales _love_ Microsoft Office. Guess who has the money and makes purchasing decisions ?
In the mean time we have to live with (the new and improved) PSpice forgetting its settings from one day to the other.
Or with (rolls drum) Teams.
No the statement is "it's worth investing in making the UX less crap to increase productivity". Either improve SW (of it's in house crap scripts, as often), switch to more performant AV, etc. etc.
It does not have to be crap actually, I have seen companies with usable machines.
O365 on the other hand, I don't see a solution, it's horrible.
> "it's worth investing in making the UX less crap to increase productivity".
I guess this is the mantra they used to redesign the Windows UI. It didn't work (they stopped at 15%). Now all they do is to use the same mantra to start over and over.
well for Windows specifically I think it's rather a managerial issue, some managers want to leave their mark, and 10% done is good enough to get promoted to other pastures and the the missing 90% become someone else's problem...
Anti-virus in practice is more about protecting about broad-spectrum attacks which aren't targeted against anyone in particular. Drive-by trojans, ransomware, and the like. An attacker like that is not going to spend an hour per target. A more motivated, targeted attacker is going to be a lot more of a threat.
This is very valid point, as developers using old machines will probably remove all "goodies" provided by manufacturer and have pretty decently running device.
When performance is a non-issue enough that schedules and features are ALLOWED to be the priority, they will always win.
When performance HURTS so much that they are forced to care about it ABOVE the pressure of features and schedules, then we get somewhere.
Which is why browser emulation doesn't work -- it doesn't inflict enough pain. They wince through it, say "well that was awful, back to rushing more features out the door" and forget about it.
I work in video games. My Lead QA recently accosted me regarding the low-spec machine being unusable. (it's an 11th Gen i5, 16GiB Ram and an Intel ARC A750).
He wanted me to get a better machine.
I politely declined indicating that this is the low spec machine, he made a fuss and I said if we can't make it run on that then we should stop making video games.
For context: The weak part for us was the CPU; the ARC A750 is a pretty poor GFX card but it should never be unplayable, it's around RTX 2060-2070 in speed, not unreasonable for a low spec machine.
It's very easy just to say yes to creeping performance demands, even in video games that are historically highly optimised. (obvious caveat here: sometimes things are not well optimised and hugely neglected)
Games are lightyears ahead of 'common use software' when it comes to usability.
Sure, there are bad, poorly optimized or simply unplayable games out there.
But still, even the lowest of them are still insanely complex when compared to the software we are complaining here, ie. text communicators.
Agree. And there is also actual progress in the rendering engines. Modern AAA games are incomparable with what they were 10 or 20 years ago. Most desktop apps on the other hand... Yes, of course they have more features than their predecessors. But still they have the same core functionality, though. A word processor is still a word processor, but modern ones come with a latency on an every button, including the old ones that didn't have it before.
The issue is not the difference in machines, the issue is that I need to run multiple apps and not just dedicate all of the resources of my machine to your app.
And don't forget phones in all of this as well. Mobile developers have the latest and greatest and fastest, but half your users will be on $60 Android pre-paid or entry-level phones that can be a factor of four or more slower than what you've been developing on.
We have minimum specifications we meet for our software (games) and a suite of old desktops (that I occasionally have to go kick) that run CI performance tests for us. It's not much investment, outside of the initial setup and generating test cases / automation, but it's been worth it for us. It's helped us find a lot of problems over the years.
Generally I’ve found that the biggest causes of performance issues are network latency and missing database indexes.
Slow laptops for developers test neither of those scenarios!
The solution is to use network emulators that can buffer packets and simulate latency. (Or just put servers in a remote cloud region instead of the local LAN.)
For databases, the trick is to give developers a slow database server with full-sized data. Don’t use empty databases (schema only) during development!
That is exactly what Michael Brown, founder of Central Point Software, insisted on back in the 1980's when they were producing the #1 selling PC software according to PC magazine.
An informed market also helped. A little bit earlier there was a comparison review published (same publication, IIRC) of the top spreadsheet programs (spreadsheets being the reason office workers were getting PC's). MBA Analyst was the best, in everything except speed, much better functionality than Visicalc, MS Multiplan or Lotus123, and only slower by a difference few users would notice without a stopwatch. MBA Analyst vanished in a flash after that article came out, and it found such a stable oblivion that it doesn't even show up on google nowadays.
As a user of "low-spec" computers, I try to avoid software written by teams of developers working under managers.
Most of the programs I use day-to-day are (a) decades old, from the distant past before so-called "tech" companies existed and/or (b) written primarily by single authors, often as a hobby or as a result of itch-scratching. Some of them are written by me.
When I occasionally compile and run the scripts and small programs I write on more powerful computers, I am amazed at the speed. Everything I write is compiled on "low-spec" computers. Today's hardware is amazing.
Where are all of you people working where you get crazy machines? I've gotten a laptop at every job that didn't let me use my own computer. They're never fast at all even when they use supposedly higher end hardware. Not even a fraction of the speed of my regular workstation.
But it's easier to optimize something to good on best in class, then to go to that from rest in case. Might even expose a developer as incompetent when it comes to hardware optimized software. Slow software bad developers.
I don't think developers are the problem here. Most developers I know would love time to work on optimizations. "When can we get this shipped???? We need it yesterday", I suspect business attitude plays the greatest role.
That was true when most software was desktop software. Most software now are Web Apps so the local speed of the development computer means less. 30 years ago there was a big difference between the performance of a current computer and a 3 year old computer. These days there isn't a huge difference and a well maintained older computer can still perform well as compared to a current computer.
But software developers do builds on that machine. I’ve quit workplaces because they wouldn’t upgrade my computer, in one case I just bought my own. It”s a chronic problem that software developers get a hand me down craptop from a salesman who couldn’t sell.
I feel like nobody really cares about optimization anymore. It's just "ship, ship, ship, move faster, ship." So there's a lot of tech-debt, a lot of unoptimized code, and a lot of "just make it work", at the expense of writing software that utilities the hardware properly.
On the flip side of that though, hardware has gotten fast enough, where this is possible.
Doesn't it all boil down to economics in the end? When I worked at AOL, QA was very important/valued because our SW was shipped on CDs (I know, I know), and every bug/update cost us users because we had to download an update at modem speed. Now that I work on a web development team, bugs are easily fixed by an update. So who cares if there's a bug? We can just update the site. There are other costs, of course -- if we tolerate lots of bugs and tech debt, making development slower, we will evenually have our lunch eaten -- that's economics too.
Users/customers accept a certain level of quality, and it doesn't make short-term economic sense to provide more.
Absolutely. It really is a double-edged sword and there's so many factors that play into.
Do you spend a ton of time writing beautifully optimized code, but ship less features, or do you ship a ton of features that mostly work. I feel like if you take too long to ship, a competitor will eat your lunch. But if everything you ship is trash, then a competitor will also eat your lunch. All about finding that balance I guess.
Total agree. There was a time when the deployment cycle was so long it was painful to ship poorly performing buggy software. Now people let their users do the testing.
Functional programmers have been in a massive propaganda campaign to actively paint optimization not just as “usually not necessary”, but actually as a negative thing.
Ask any developer what they think of optimization, and the vast majority will respond “optimization is the root of all evil” or some other nonsense variant.
Now that they’ve successfully paint optimization as bad, they’re working on painting any profiling or measurement at all as bad.
They need this because the performance characteristics of pure functional programming is pretty dogshit.
You also find hordes of developers that selectively care. Watching Python developers shit on Java for “being too slow” is getting pretty old.
Yeah and personally I've been on both ends of the spectrum. I think there is something to be said for pre-mature optimization and over-optimization. But I do feel like it's a lost art these days.
The quote means to not assume something is slow, but to actually measure it.
Pure Functional Programmers state that you should not even measure performance. They take this position because despite their many claims that Pure FP is performant, it turns out that if you measure it, it’s not performant.
"int" is not boxed but "Integer" is. You can't use primitive types like "int" inside generic type arguments so in that case you're forced into using the boxed integer type.
Functional programmers have been in a massive propaganda campaign to actively paint optimization not just as “usually not necessary”, but actually as a negative thing.
Based on what? FP advocates like performance as much as anyone else.
They need this because the performance characteristics of pure functional programming is pretty dogshit.
Research languages like ATS show that functional programming doesn't come at the price of performance.
lol. No they don’t. The official line from /r/haskell is “all optimization is the root of all evil”.
Nobody is going to use theorem proving languages for a lot of reasons, but actually, mostly cause functional programmers did themselves in with their other ridiculous propaganda campaign to declare that developer time is too expensive.
If ATS is a pure functional programming language, then it by definition of how cpus work cannot be performant, although there may be some things it can match other languages (usually reads are not noticeably slower)
I'm puzzled by this read on the situation. For starters, vanishingly few programmers work in a pure functional context. Secondly, performance characteristics of functional programming are absolutely not dogshit. There are specific languages/VMs/etc that have inherent performance issues, but that's not a universal truth. To claim that would be like pointing at Ruby and saying that imperative programming is slow.
I think maybe a more measured take is that many modern environments remove the developer sufficiently from the actual execution of their code that performance optimization becomes much less obvious and straightforward.
Also, and this is just my personal experience, but I've basically never heard anyone actually claim that optimization is bad or unnecessary. I have never, ever heard anyone claim that profiling tools are bad.
What I have repeatedly heard is that there often isn't a compelling business case for performance optimization. Unfortunately that's probably correct a lot of the time.
I really think you're pointing at the wrong folks here. The hordes of JS devs out there who are deprioritizing perf aren't doing so because they think it's fundamentally a bad thing to optimize, that's just a self-apparently ridiculous notion, they are doing so because they work in a culture that values delivery of features massively more than optimization.
I don’t think that has anything to do with FP honestly. I think it’s a combination of package culture, the language making it incredibly easy to write poorly performing code, and the massive scale and cultural/corporate tilt of the JS community resulting in a generally lower quality of developer.
Functional programmers have long worked to improve the compiler optimization of functional language implementations. This is how we got innovations like the continuation passing style (first used for compiling Scheme), deforestation, defunctionalization, tail call elimination, and strictness analysis (for lazy languages like Haskell).
Also, a lot of literature on improving garbage collection came from trying to improve the speed of a functional language like Lisp or Standard ML.
It seems to me that functional programmers tend to care more about optimization than e.g. Python or Ruby developers, because functional programming has a long history of being perceived as slow and they want to change it. Scheme, OCaml, Standard ML, and Haskell all have implementations that perform well and compile to assembly.
> I feel like nobody really cares about optimization anymore.
You have to consider the survivorship bias. Maybe the people that care about optimization don't 'survive' to keep caring about it.
> It's just "ship, ship, ship, move faster, ship."
Are startup with that mentality more likely to do well?
I've built my career around performance work and I've noticed that there a time and a place for everything. Sometimes shipping is more important, and sometimes performance can be a day one defining feature.
I feel like nobody really cares about optimization anymore.
Until customers care about performance/optimization, most businesses won't care. Eventually there will come a day where hardware will stagnate sufficiently to incentivize software efficiency.
Users do care about speed. They complain about it all the time, you just have to listen to them. It's most of the "features" that users couldn't give a crap.
So why aren’t the users picking the software that’s faster instead of the ones with more features. Why does everyone use the “bloated” Gmail webui instead of some barebones desktop client that’s a few ms faster?
I recently switched an old PHP project from sending me emails directly via SMTP to using mailgun. At first I tried to use their SDK. It pulled in like a dozen dependencies. I gave up on that idea and replaced it with a simple curl call.
I had very similar experience with npm. Especially when you need to merge all the security updates for the sdk and all their dependencies. I also prefer interacting with the api, if it is straightforward.
It feels true but I don't think it actually is. Especially given the fact Wirth wrote it in 1995 which is practically the pinnacle of what most of us perceive as when software was actually fast.
It could have been true the whole time. Perhaps software has been getting slower, and it's gotten so much slower and more bloated that 1995 software seems lean and fast by our modern standards, when by 1980s Wirthian standards, it wasn't.
I'm not convinced this is true and not just a popular argument.
Just today I've processed 4 TB of JSON data, in Python, on a desktop computer. That would be crazy to imagine 10 years ago. Yes, many cores, fast SSD, etc. Maybe it should be 20 TB if ultra optimized, but the capability advance is incredible.
Yes, apps maybe start slowly, but now everybody can easily edit HD video on their mid-range laptop.
"Computers are in fact very fast" and "certain programs do in fact demonstrate that" and "the real-world experience of using computers for most people is that performance is largely treading water or going backwards" due to a boom in software inefficiency, can all be true at the same time.
I wonder if everything becoming a saas has to do with that. Everyone has added a bunch of network hops to services that (probably) have to make a bunch of network hops.
It will be interesting to see if that changes in a post zero interest rate world. Will people do more locally in their programs instead of reaching out to third party saas to save money? Will performance be a value add in competitive niche markets?
Software does more than it used to. Try using an old PC, say Windows 98. You will be amazed how little functionality there is. It didn't even come with full-screen desktop wallpaper.
Is this really true that software is getting slower? I've been using a budget Windows 10 desktop lately, and I'm shocked by how fast everything is running: ESRI ArcGIS, Firefox, code editors, etc. I remember having a budget desktop PC back in the mid 2000's and it was a significantly worse experience on very basic workflows (Excel, regular web browsing, etc)
Agreed. Between SSDs, blazing faster home DSL internet, and multicore processors, using a computer is much faster than it's ever been before.
Sure there's more software bloat, and webpage bloat, but if anything the overall user experience has gotten faster. And that's even with resource hogs like Retina displays and 4K video.
Like, go look up YouTube videos of people using older systems (not VM's). A Mac in 1989 takes forever to open an application, open a file, or save a file. The HDD clicking away... Remember how Word implemented "fast save" to shorten save times, which appended a lot of changes rather than rewriting the whole file? Nobody worries about that today.
When we're trying to reproduce what older systems were like, it's important not to be combining software from earlier era on hardware from a later one.
> Between SSDs, blazing faster home DSL internet, and multicore processors, using a computer is much faster than it's ever been before.
How much faster? Our hardware is several orders of magnitude faster than 20-30 years ago. And yet it takes multiple seconds to start even the simplest app doing nothing, and don't get me started on more complex software
> And yet it takes multiple seconds to start even the simplest app doing nothing
This is what I don't get when people say. On my MacBook, I just launched TextEdit. The entire "launch" time is basically taken up by a window zoom effect that is maybe half a second.
I just put chrome://restart into my browser bar, and Chrome quit and fully relaunched in about three quarters of a second. (And then obviously it takes more time to load the tab contents.)
Double-clicking on a multi-page, 2 MB PDF takes about two-thirds of a second to open Preview and render.
As far as I'm concerned, everything's lightning fast. There's absolute no "taking multiple seconds", whether it's a simple text editor or an entire web browser.
Macs are now crazy fast due to insane advances in their CPU. On intel macs you could definitely feel the slowdown of all software.
I mean, they advertised "instant wake up from sleep" as a feature... That Macs had in 2008.
I have a Windows machine that starts from NVMe. It takes a full minute for it to start a handful of startup apps, also in NVme: Firefox, Steam, 1password. What is it doing?
I just clicked around on some apps on my iPhone 13 that I haven’t used in ages and they all opened in under 1 second. It looks like they basically open instantly but some make a network request to load the first page.
Hard drive to SSD was a really big deal for general desktop experience. I used a ~first gen 30gb ssd with an intel atom for a while and that was fine provided I didn't try to compile anything. If your budget desktop has the OS on flash, that would do it.
I tried actually looking for anyone who actually did experiments to confirm whether or not software is getting slower and... uh... I can't really find anyone who has done such an experiment. Possibly, this is just the shittification of search, but everything that turns up is essentially just a link to a thought piece on the bloat of software, which almost invariably degenerates into shitting on Electron.
On anecdotal evidence, one thing I recall from the late 90's/early 00's era of computing is the sheer prevalence of splash screens. If you wanted to open an application up, the first thing it displayed was a splash screen, with a progress bar that would animate to show you that it was doing something. And these splash screens have become far less prevalent in modern software, which at least anecdotally throws some doubt on Wirth's Law.
Do you think running Windows 10 on the PC from the mid 2000s would be a better or worse experience than running the software that ran om that machine at the time?
Running Windows 11 on the same exact machine that I ran Windows 10 on, has been a dramatically worse experience performance-wise.
There are several noticeable and unforgivable performance issues that I experience regularly with WIN11.
The most-painful is that the WIN11 START MENU will occasionally (about once or twice per day) for no apparent reason, stop responding for 30-45 seconds.
During this period, keystrokes are not responded to (but they are going into the keyboard buffer). When it recovers from its "blackout" it will spit out everything in the keyboard buffer.
WTF is it doing during those 45 seconds?
I can't prove it but I would bet money that it is trying to send telemetry to the Mother-Ship and got its request "load-balanced" onto a node that is not responding.
More efficient use of a resource results in people using more of that resource, not less. Creating more efficient gasoline engines doesn’t cause people to use less fuel, they all just buy larger cars now.
I am pretty certain that if you stripped away most of the abstractions (law of leaky abstractions) and wrote software that was optimized to the hardware design per se, then you be able to write software that is blazingly fast.
Look up how many steps your favorite language is going through before hitting the cpu.
No wonder shit is slow when all we do is stacking abstractions and not concentrating on removing them.
Anecdotally this does not apply to my laptop from 2014. It was born with a HDD and upgraded to SSD a couple of years later. It still feels fast enough and, more up to the point, it doesn't feel to get any slower by the years. Actually it's getting faster and that was the feeling I had with my previous laptop from 2006.
OK, I've been using Linux on them since January 2009, so no Microsoft software (but Teams is slow, I installed it a couple of years ago and uninstalled it.) I used Ubuntu until one year ago, then Debian.
In all those years JavaScript browser engines got much faster for everybody, not only for me. Browsers are faster now. Some sites are slower but NoScript and uMatrix take care of most of those problems. They add others, such as fiddling with settings to enable as little of JS to make the sites work. Maybe I should account the time I spent doing that as part of the slowdown.
Everything else I use is at least as fast as it used to be. Let's see what I have open right now on my screen: emacs, Thunderbird, VLC, KeePassXC, Slack, Telegram. Slack has never been fast but it's not slow either. LibreOffice is fast enough and it doesn't feel slower than what I remember it to be. And in the background: some docker containers (three PostgreSQLs, one redis,) a Rails app + Sidekiq, a Django app + Celery, one webpack for a Vue.js SPA. They are OK and this computer is a few times slower than what I could buy now.
So, some software eat up all the hardware improvements of the last 10 years, some other software didn't or actually improved.
Edit: of course I also have a browser open on my screen. Firefox with one window per virtual screen and many tabs per window. htop is saying 15.7/31.1GB.
> Anecdotally this does not apply to my laptop from 2014.
It doesn't apply to anyone device, this is a comparison of generation over generation changes. Your 2014 laptop is closer to a 2018 laptop than 2014 software is to 2018 software.
Yeah the only bit of software I’d think of as slow is Steam. Everything else is incredibly snappy. My iPhone is several years old now and it never misses a frame. My MacBook M1 is 3 years old and feels brand new still.
Use Telega (Emacs) for Telegram, and try Notmuch with mbsync (isync) and msmtp. If you want I can tweak your ~/.emacs for that.
On Slack, there's a libpurple plugin, and Bitlbee supports that. If you use Erc with Bitlbee, you could connect to any plugin Bitlbee uses (and the internal protocols too OFC).
Sometimes software bloat is what it is. Poorly written and unoptimized.
Other times, that performance loss was actually an intentional trade-off for accessibility, security, reliability, or other tangible benefits. I'm sure not everyone will agree, but in most cases I will personally prioritize those ahead of performance.
A lot of the older simpler software we think of as being high performance was, or still is, severely lacking in those aspects.
This has proven true for a while now. My favorite example is Slack. Slack is solid software, but why do we need upwards of 300MB of memory usage to send text and a couple images.
I know why, but it does seem like an unreasonable usage.
Here's the thing: I'd be okay with my "primary" software to be resource intensive. In my case, that's my IDE and the surrounding tools supporting it. I don't want my supporting software (Slack, Spotify, etc) to be taking a ton of resource. But everyone thinks their software is worth the memory usage. That ends up leaving us with Spotify actively taking 300ish MB of RAM to play music I could play off of VLC instead.
Who this really hurts are the users that's don't want to spend a lot on their machines. A lot of us devs have powerful and nice machines because it's a clear value win for us to do so, but then tons of users suffer because you're not even realizing you're writing insanely suboptimal code.
The amount of times I've seen things that abuse network traffic to is insane. Everytime I see some SQL in a loop that should be a single query, a piece of me dies.
This is probably just a natural thing we're experiencing with software development though, and I don't expect it to go away. The best we can do is to write better software and review our peer's code as well.
I think a lot of it is that Electron, as a technology, trades off cheaper developer expense (fewer devs needed to target more platforms) for much worse end user performance (slower, more ram).
Externalising the cost on users means the company doesn't have to pay it.
Developers are expensive after all, and there's no material loss for slack (except negative sentiment like this) - ultimately: you still use (and pay) for the software, so why should they care?
I can't find the video anymore, but there was a team viewer video talking about a performance update on youtube, showing how it went from taking 20 seconds to start up to... 10 seconds.
Hardware is interesting now that Moore's Law (or Dennard scaling) has flatlined 10 years ago--are college courses now taught any differently because of this? It's a significant issue of computational resources in that we can't assume exponential transistor density anymore.
192 comments
[ 3.9 ms ] story [ 231 ms ] threadAs long as devs spend their days with bugattis while writing software for corollas, this will continue to get worse.
It's the devs that need the slow machines -- they're in the tightest feedback loop, and directly empowered to optimize performance.
In other words, the business should have ultimate authority and responsibility to structure incentives and pursue priorities. Up until the engineer crosses over a boundary and becomes part of leadership.
A common complaint on HN is bloated web performance. Surely we don't think the web is bloated because of too much custom code as opposed to too many off-the-shelf components?
In many cases, taking performance into account up front adds little overhead and won’t appreciably affect the design. But, if you codify some algorithmically inefficient approach into your public API, you’re going to find that hard to unwind. The engineering team should advocate for that when designing the product.
Tons of software would run faster if it DIDN'T use custom stuff. Don't load a JavaScript framework for form validation if using `required` and `pattern` are enough. Don't write your own sorting algorithm unless it's faster than qsort(). Don't write your own data storage engine if SQLite covers your use case.
Story time: I once wrote a memset() replacement because one compiler kept optimizing out my memset() call and didn't have memset_s(). It slowed my program down a lot. When I looked carefully I saw I was always resetting the whole buffer, even though I was keeping track of how much had been written to it. Fixing that lead to a ~10x speedup (0.1s to process a large word processor document went to 0.01s, occasionally 0.02s).
Most software is made by stitching together off-the-shelf components. I don't think people on the web need a warning about not writing too much custom code. The HN complaint about the web is regarding bloat from people who walk the mainstream road of web development. Loading a bloated framework to do whatever is an example of such mainstream development.
There might be a case for specifically running testing on a slower machine, though.
How so? Do the heavy tools need to run alongside the app? Are you thinking of something like Android emulator? For that scenario, keep the beastly workstation, but switch to a $150 phone.
> It means their app will feel slow no matter what.
If you can make it feel fast or at least responsive on your underpowered machine, it should feel super fast on everything else. Even today's slowest machines can run some things fast. It does depend a bit on your market though; it might not be worth the effort, but there's a lot of applications out there that could use some speed.
Straw man. Of course, if you crank that knob to the extreme bad things happen.
There might be a case for specifically running testing on a slower machine, though.
Agreed here. I think the optimal is for devs to be able to do intensive operations on a fast machine, dogfood for most of their time on a average machine, then test on a somewhat slow one.
Forcing them to CARE about targeting benchmark/latency metrics is the sticking point. And that requires shoving their face in it for long enough that it becomes unbearable.
If anything, give the C-suites the shitbox laptops.
On mobile I've always gone back to testing on low end hardware, there are just too many inconsistencies when trying to simulate slower performance, outdated OS problems, touchscreen drivers, etc.
(second-hand information) Android was at a smoothness disadvantage vs iOS for a long time, because it was never an organization level priority for devices to scroll at >= 60hz without stuttering. Then some executives went "why is scrolling so bad on our phones but not on Apple's?" and suddenly it became a priority.
I remember before the priorities changed, some of their graphics programmers were very frustrated that they didn't have the freedom to invest in fixing it.
Luckily, Chrome has a feature to deliberately throttle the CPU and network speed for precisely this reason.
Sadly hardly anyone uses it.
It would be great if Chrome's Developers would use something similar to run Chrome itself.
This feature is currently part of devtools. But if it could be enabled as part of Chromes policy engine, then IT departments could enable it by default for all developers, managers, and everyone working on the product, specifically for only web URL's of the product itself.
So: If you want to help solve the fact computers are slow for everyone, probably one of the most impactful things you could do is to send a PR to the Chromium project to let the network and CPU slowdown code[1] be possible to activate from the policy code [2].
[1]: https://source.chromium.org/chromium/chromium/src/+/main:thi...
[2]: https://source.chromium.org/chromium/chromium/src/+/main:chr...
You want the fast machine because you want the code-build-test cycle to be fast, but for immediacy reasons we want a little more hardware than we really need so that we don't get bogged down too badly in worst-case scenarios.
So when we run the software on the machine along side this behemoth, we may or may not see something comparable to the users.
And then we also like for interactions to go faster for us so that we can quickly get to the end of a thought without having to drop everything and fix the slowness first (also, too few of us actually know how to fix the slowness instead of papering over it).
As we lean into multiple machines, or at least virtual machines, I can see a sliver of hope here where we offload rather large chunks of the IDE to resources the application itself cannot 'see', due to partitioning, remote calls, or both. Things like running the language server elsewhere, or the application in a container.
But then you talk to end users and it turns out they work 80 hours on one big document with input lag of several seconds. Some actions can take 15 seconds. It’s mad. It’s larger than anything we imagined anyone to work on. It must be infuriating. And they don’t get beefier machines despite it being an instant cost saving. Because software is seen as magical anyway. They do in two days what would take 50 days to calculate by hand! That’s fast! So when you ask them what to prioritize surely they say “make it faster with heavy documents”? No, they want more features. Because a feature can save then days or weeks or months. A faster program just saves them hours. So I sort of understand them (and why we build software that grows slow).
The machine performs half of 12 boring jobs at the bank needed every month. But there is still another half dozen jobs the IBM still cannot do. It doesn't have the punch cards. So the roomful of smokers does the rest of the jobs in a couple of weeks, ready just in time to start over with next months tasks.
Should IBM make the machine or its programs twice as fast, or have twice as many features, even if the programs are half as fast? They should double the amount of features. And double it again, and again, and again...
But scale those "close to nothing" downsides times 7billion people, 100k seconds in a day, 365 days a week. And suddenly, the ammount of time and electricity alone wasted on something like, waitiing for windows explorer to start, adds to real world scales.
...But also, this implies that optimizing is inherently costly. Which is not always the case. Just the culutre of 'not caring' makes things go slower then they could, while still using the same high level languages etc.
Giving bad tools to any professional is a bad idea for productivity. We have other ways of checking if software is slow.
It is all a question of company priorities as there are no professional standards whatsoever established. And companies ofc go for spend the least they can get away with.
Between disk encryption, anti virus, IT asset management, data custody tracking, etc; my PC is as slow as molasses.
Unfortunately I think its slow in a different way that low-spec machines are slow. Mine is very slow on IO ops, but I have 32GB of RAM and a 20-core i7, so plenty of resources available even after all the BS.
However we DONT want annoying "my computer slow" calls. So we can talk.
But you need the antivirus and some kind of intune/rmm software, sorry.
The company can live with your loss of productivity because it is living with the loss of everyone's productivity. The company cannot live without security.
On top of that, if you are the only one making noise about slow computers and complaining about stuff and things then you eventually end up being the problem. I mean, why is that lone employee complaining so hard about wanting to remove security assurances from his machine?
We tried. Managemen and sales _love_ Microsoft Office. Guess who has the money and makes purchasing decisions ? In the mean time we have to live with (the new and improved) PSpice forgetting its settings from one day to the other. Or with (rolls drum) Teams.
It does not have to be crap actually, I have seen companies with usable machines.
O365 on the other hand, I don't see a solution, it's horrible.
I guess this is the mantra they used to redesign the Windows UI. It didn't work (they stopped at 15%). Now all they do is to use the same mantra to start over and over.
That's BS. Like there was no such things as featuritis and unreasonable schedules.
When performance HURTS so much that they are forced to care about it ABOVE the pressure of features and schedules, then we get somewhere.
Which is why browser emulation doesn't work -- it doesn't inflict enough pain. They wince through it, say "well that was awful, back to rushing more features out the door" and forget about it.
That won't happen because management people are the ones with Bugattis. You got the wrong target.
He wanted me to get a better machine.
I politely declined indicating that this is the low spec machine, he made a fuss and I said if we can't make it run on that then we should stop making video games.
For context: The weak part for us was the CPU; the ARC A750 is a pretty poor GFX card but it should never be unplayable, it's around RTX 2060-2070 in speed, not unreasonable for a low spec machine.
It's very easy just to say yes to creeping performance demands, even in video games that are historically highly optimised. (obvious caveat here: sometimes things are not well optimised and hugely neglected)
Slow laptops for developers test neither of those scenarios!
The solution is to use network emulators that can buffer packets and simulate latency. (Or just put servers in a remote cloud region instead of the local LAN.)
For databases, the trick is to give developers a slow database server with full-sized data. Don’t use empty databases (schema only) during development!
That is exactly what Michael Brown, founder of Central Point Software, insisted on back in the 1980's when they were producing the #1 selling PC software according to PC magazine.
An informed market also helped. A little bit earlier there was a comparison review published (same publication, IIRC) of the top spreadsheet programs (spreadsheets being the reason office workers were getting PC's). MBA Analyst was the best, in everything except speed, much better functionality than Visicalc, MS Multiplan or Lotus123, and only slower by a difference few users would notice without a stopwatch. MBA Analyst vanished in a flash after that article came out, and it found such a stable oblivion that it doesn't even show up on google nowadays.
Most of the programs I use day-to-day are (a) decades old, from the distant past before so-called "tech" companies existed and/or (b) written primarily by single authors, often as a hobby or as a result of itch-scratching. Some of them are written by me.
When I occasionally compile and run the scripts and small programs I write on more powerful computers, I am amazed at the speed. Everything I write is compiled on "low-spec" computers. Today's hardware is amazing.
[1] https://css-tricks.com/test-your-product-on-a-crappy-laptop/
On the flip side of that though, hardware has gotten fast enough, where this is possible.
Users/customers accept a certain level of quality, and it doesn't make short-term economic sense to provide more.
Do you spend a ton of time writing beautifully optimized code, but ship less features, or do you ship a ton of features that mostly work. I feel like if you take too long to ship, a competitor will eat your lunch. But if everything you ship is trash, then a competitor will also eat your lunch. All about finding that balance I guess.
Functional programmers have been in a massive propaganda campaign to actively paint optimization not just as “usually not necessary”, but actually as a negative thing.
Ask any developer what they think of optimization, and the vast majority will respond “optimization is the root of all evil” or some other nonsense variant.
Now that they’ve successfully paint optimization as bad, they’re working on painting any profiling or measurement at all as bad.
They need this because the performance characteristics of pure functional programming is pretty dogshit.
You also find hordes of developers that selectively care. Watching Python developers shit on Java for “being too slow” is getting pretty old.
Pure Functional Programmers state that you should not even measure performance. They take this position because despite their many claims that Pure FP is performant, it turns out that if you measure it, it’s not performant.
Hence “don’t measure”.
Look on something like java or kotlin, that are inherently slowing down EVERY.SINGLE.VARRIABLE. access by boxing them into objects.
On other hand there is rust, which takes quite a bit of inspiration from fp aproach but obviously still cares about the performance.
Based on what? FP advocates like performance as much as anyone else.
They need this because the performance characteristics of pure functional programming is pretty dogshit.
Research languages like ATS show that functional programming doesn't come at the price of performance.
Nobody is going to use theorem proving languages for a lot of reasons, but actually, mostly cause functional programmers did themselves in with their other ridiculous propaganda campaign to declare that developer time is too expensive.
If ATS is a pure functional programming language, then it by definition of how cpus work cannot be performant, although there may be some things it can match other languages (usually reads are not noticeably slower)
That claim doesn't match my experience at all. Can you give some examples of that attitude being demonstrated on /r/haskell?
I think maybe a more measured take is that many modern environments remove the developer sufficiently from the actual execution of their code that performance optimization becomes much less obvious and straightforward.
Also, and this is just my personal experience, but I've basically never heard anyone actually claim that optimization is bad or unnecessary. I have never, ever heard anyone claim that profiling tools are bad.
What I have repeatedly heard is that there often isn't a compelling business case for performance optimization. Unfortunately that's probably correct a lot of the time.
I really think you're pointing at the wrong folks here. The hordes of JS devs out there who are deprioritizing perf aren't doing so because they think it's fundamentally a bad thing to optimize, that's just a self-apparently ridiculous notion, they are doing so because they work in a culture that values delivery of features massively more than optimization.
Also, a lot of literature on improving garbage collection came from trying to improve the speed of a functional language like Lisp or Standard ML.
It seems to me that functional programmers tend to care more about optimization than e.g. Python or Ruby developers, because functional programming has a long history of being perceived as slow and they want to change it. Scheme, OCaml, Standard ML, and Haskell all have implementations that perform well and compile to assembly.
You have to consider the survivorship bias. Maybe the people that care about optimization don't 'survive' to keep caring about it.
> It's just "ship, ship, ship, move faster, ship."
Are startup with that mentality more likely to do well?
I've built my career around performance work and I've noticed that there a time and a place for everything. Sometimes shipping is more important, and sometimes performance can be a day one defining feature.
Until customers care about performance/optimization, most businesses won't care. Eventually there will come a day where hardware will stagnate sufficiently to incentivize software efficiency.
They do, Businesses and programmers are incapable of listening to them
Users primarily care about features first and speed second.
This software exists? When all your alternatives are bloated enshittificated crap, what exactly can I as a user chose?
Just today I've processed 4 TB of JSON data, in Python, on a desktop computer. That would be crazy to imagine 10 years ago. Yes, many cores, fast SSD, etc. Maybe it should be 20 TB if ultra optimized, but the capability advance is incredible.
Yes, apps maybe start slowly, but now everybody can easily edit HD video on their mid-range laptop.
We had this in 2013. Would have handled the job with a well written parser.
https://www.intel.com/content/www/us/en/products/sku/77779/i...
~10 years ago I parsed 15GB of Windows binary logs with xargs, grep and strings(1) in minutes. Minutes. Less than 1/4 of an hour.
It will be interesting to see if that changes in a post zero interest rate world. Will people do more locally in their programs instead of reaching out to third party saas to save money? Will performance be a value add in competitive niche markets?
Sure there's more software bloat, and webpage bloat, but if anything the overall user experience has gotten faster. And that's even with resource hogs like Retina displays and 4K video.
Like, go look up YouTube videos of people using older systems (not VM's). A Mac in 1989 takes forever to open an application, open a file, or save a file. The HDD clicking away... Remember how Word implemented "fast save" to shorten save times, which appended a lot of changes rather than rewriting the whole file? Nobody worries about that today.
"Windows NT on 600MHz machine opens apps instantly. What happened?"
https://news.ycombinator.com/item?id=36446933
https://news.ycombinator.com/item?id=36447704
There's also the note that this person was running NT on a later system far, far faster than it was designed for:
https://news.ycombinator.com/item?id=36447461
When we're trying to reproduce what older systems were like, it's important not to be combining software from earlier era on hardware from a later one.
How much faster? Our hardware is several orders of magnitude faster than 20-30 years ago. And yet it takes multiple seconds to start even the simplest app doing nothing, and don't get me started on more complex software
This is what I don't get when people say. On my MacBook, I just launched TextEdit. The entire "launch" time is basically taken up by a window zoom effect that is maybe half a second.
I just put chrome://restart into my browser bar, and Chrome quit and fully relaunched in about three quarters of a second. (And then obviously it takes more time to load the tab contents.)
Double-clicking on a multi-page, 2 MB PDF takes about two-thirds of a second to open Preview and render.
As far as I'm concerned, everything's lightning fast. There's absolute no "taking multiple seconds", whether it's a simple text editor or an entire web browser.
I mean, they advertised "instant wake up from sleep" as a feature... That Macs had in 2008.
I have a Windows machine that starts from NVMe. It takes a full minute for it to start a handful of startup apps, also in NVme: Firefox, Steam, 1password. What is it doing?
On anecdotal evidence, one thing I recall from the late 90's/early 00's era of computing is the sheer prevalence of splash screens. If you wanted to open an application up, the first thing it displayed was a splash screen, with a progress bar that would animate to show you that it was doing something. And these splash screens have become far less prevalent in modern software, which at least anecdotally throws some doubt on Wirth's Law.
There are several noticeable and unforgivable performance issues that I experience regularly with WIN11.
The most-painful is that the WIN11 START MENU will occasionally (about once or twice per day) for no apparent reason, stop responding for 30-45 seconds.
During this period, keystrokes are not responded to (but they are going into the keyboard buffer). When it recovers from its "blackout" it will spit out everything in the keyboard buffer.
WTF is it doing during those 45 seconds?
I can't prove it but I would bet money that it is trying to send telemetry to the Mother-Ship and got its request "load-balanced" onto a node that is not responding.
More efficient use of a resource results in people using more of that resource, not less. Creating more efficient gasoline engines doesn’t cause people to use less fuel, they all just buy larger cars now.
Look up how many steps your favorite language is going through before hitting the cpu.
No wonder shit is slow when all we do is stacking abstractions and not concentrating on removing them.
https://news.ycombinator.com/item?id=35351760
OK, I've been using Linux on them since January 2009, so no Microsoft software (but Teams is slow, I installed it a couple of years ago and uninstalled it.) I used Ubuntu until one year ago, then Debian.
In all those years JavaScript browser engines got much faster for everybody, not only for me. Browsers are faster now. Some sites are slower but NoScript and uMatrix take care of most of those problems. They add others, such as fiddling with settings to enable as little of JS to make the sites work. Maybe I should account the time I spent doing that as part of the slowdown.
Everything else I use is at least as fast as it used to be. Let's see what I have open right now on my screen: emacs, Thunderbird, VLC, KeePassXC, Slack, Telegram. Slack has never been fast but it's not slow either. LibreOffice is fast enough and it doesn't feel slower than what I remember it to be. And in the background: some docker containers (three PostgreSQLs, one redis,) a Rails app + Sidekiq, a Django app + Celery, one webpack for a Vue.js SPA. They are OK and this computer is a few times slower than what I could buy now.
So, some software eat up all the hardware improvements of the last 10 years, some other software didn't or actually improved.
Edit: of course I also have a browser open on my screen. Firefox with one window per virtual screen and many tabs per window. htop is saying 15.7/31.1GB.
It doesn't apply to anyone device, this is a comparison of generation over generation changes. Your 2014 laptop is closer to a 2018 laptop than 2014 software is to 2018 software.
On Slack, there's a libpurple plugin, and Bitlbee supports that. If you use Erc with Bitlbee, you could connect to any plugin Bitlbee uses (and the internal protocols too OFC).
Other times, that performance loss was actually an intentional trade-off for accessibility, security, reliability, or other tangible benefits. I'm sure not everyone will agree, but in most cases I will personally prioritize those ahead of performance.
A lot of the older simpler software we think of as being high performance was, or still is, severely lacking in those aspects.
I know why, but it does seem like an unreasonable usage.
Here's the thing: I'd be okay with my "primary" software to be resource intensive. In my case, that's my IDE and the surrounding tools supporting it. I don't want my supporting software (Slack, Spotify, etc) to be taking a ton of resource. But everyone thinks their software is worth the memory usage. That ends up leaving us with Spotify actively taking 300ish MB of RAM to play music I could play off of VLC instead.
Who this really hurts are the users that's don't want to spend a lot on their machines. A lot of us devs have powerful and nice machines because it's a clear value win for us to do so, but then tons of users suffer because you're not even realizing you're writing insanely suboptimal code.
The amount of times I've seen things that abuse network traffic to is insane. Everytime I see some SQL in a loop that should be a single query, a piece of me dies.
This is probably just a natural thing we're experiencing with software development though, and I don't expect it to go away. The best we can do is to write better software and review our peer's code as well.
Externalising the cost on users means the company doesn't have to pay it.
Developers are expensive after all, and there's no material loss for slack (except negative sentiment like this) - ultimately: you still use (and pay) for the software, so why should they care?
There was a lot of comment when this was posted here.
...dear God, what is wrong with this industry...