"Software is getting slower more rapidly than hardware becomes faster."

There might be a case for specifically running testing on a slower machine, though.

(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.

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).

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.

That's BS. Like there was no such things as featuritis and unreasonable schedules.

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/

Users/customers accept a certain level of quality, and it doesn't make short-term economic sense to provide more.

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.

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.

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.

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.

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).

There was a lot of comment when this was posted here.

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.

* Application code is issuing too many queries to the database. The classic N+1 problem is of this type. Another common problem is issuing one query for each item in a set, when an aggregate query could be issued instead. For example, suppose we have a database that contains students and exams, and every time a student takes an exam, a row is added to the table student_exam with the student id and the exam id. Now suppose that we want to build a dashboard that lists each exam and the number of students that took each exam. We could do this by iterating through the exam ids and querying

    SELECT COUNT(*) FROM student_exam WHERE exam_id = ?

    SELECT exam_id, COUNT(*) FROM student_exam GROUP BY exam_id

* Missing database indexes. A lot has been written about this, and it can cause a slowdown of N or N^2 times in some cases. Adding an index in the right place can change a linear scan into a much faster B-tree search.

* Too much overhead. If your request handler is performing a small number of operations, but they include slow operations like making API calls over the network, then your handler will be slow, and network problems could make it even slower. If you’re writing Java code that has to make calls ten levels deep to get anything done, those levels of indirection aren’t free.

* Using the wrong data structures, or using them suboptimally. If you want to determine whether two lists have an element in common, you could loop through both lists, but this will take O(mn) time. The faster way is to build a search structure out of one of the lists, then go through the other list and look for its elements in the search structure. For example, if your lists are A and B, you can build an AVL tree out of list A, call this tree T, then look for each element of B in T. This will run in O((m+n) log n) time. Using a hashtable works here too. Another common cause for slowdown is constructing a string by adding to its end repeatedly. This usually causes quadratic running time; it is better to build a list of strings and then concatenate them at the end.

In the abstract, these cases are the same as having a double loop in your code; the difference is that the double loop isn’t in your code, it’s in library code or in the database’s code. So you should avoid writing code that is slow like this, but you should also avoid calling code in a way that will cause slowdowns.

My third point is a little different from the rest; it’s not really talking about slowdowns by a factor of n, but by a large constant factor. When we’re talking about theory, we normally ignore the constant factors… but in the real world, those constants can matter a lot. This is why things like bitsets and B-trees are used. They only provide a constant factor improvement over regular sets and binary search trees respectively, but that constant factor sometimes matters a lot.