Chrome will not run properly on first execution, as in ran for the first time after a cold start of the computer, when executed off a HDD. Why? Because the HDD takes too long to read off data. Chrome expects SSD latency and fuck your computer if it's not residing on one.
When executed off a HDD, I've found Chrome only runs properly from second execution onwards after the underlying operating system has cached most of the stuff Chrome wants in RAM in anticipation of subsequent executions.
I want to say this is optimization for ever more powerful hardware, but I'm inclined to say it's also sheer incompetency that Chrome literally can't fallback gracefully if it doesn't get data as quickly as it wants.
"Oh, you know that 32 GB machine you've got? We're replacing it with this new 16 GB one. If the test suite is too slow on your new machine, I guess you'll just have to make the tests faster."
EDIT: Also - client side native software and web dev are insanely different. Web/ serverside people seem to disregard this. Constantly.
I cannot parse this sentence. What does vista having its minimum requirements poorly defined have to do with being forced to develop on underpowered hardware?
If my boss says “we are giving you a worse machine because we think that will make you write better code” I am out of there. There are plenty of ways to emulate weaker hardware and do performance testing and to make it a development priority that don’t involve intentionally hamstringing your engineers.
You’re all over the place. Please explain why you think using underpowered hardware is the only legitimate way to write software that works on that hardware.
In particular I often fight the slowest machine leaving the office. That should stay for a long time, set aside for testing.
Testing only in a VM on a beefy dev box leads to terribly performing software on customer machines. There's a multitude of performance problems that only come up when a system starts paging to disk, a machine has a HDD, or a CPU gets maxed out. These issues will be completely occulted on a dev machine with tons of RAM, 16 cores, and an NVMe disk.
Far too many developers have the beefy dev box with no requirements to test on more prosaic configurations. Even limiting a VM's CPU and memory isn't a good environment for performance testing because it's still faster than actual low end hardware.
Basically: An end-user has computer with 4GB of DDR3. Devs for <software> wrote for and tested on a machine with 64GB of DDR5. <Software> ends up running like shit on end-user's computer.
It isn't the end-user's problem that the software runs like shit, because the devs programmed to an unrealistic common denominator. The end-user is going to find <software> that doesn't run like shit on his computer, and the devs only have themselves to blame for losing a customer because they were so out of tune with reality.
It may not be their fault but it almost certainly is their problem…
I have to say, I appreciate the insane expertise browser engine developers have in making JS and layouting run fast.
Which, unlike making everyone develop on palm-pilots, is the correct solution to performance problems.
Make sure nothing else is running, start the application, expect failure, start it again, works as expected.
The end result is that anything I type gets jumbled or overwritten multiple times before the page settles down and can actually be used.
Obviously, it can be done right, but it seems that most devs who are so eager to jump on the async bandwagon have no idea that they have to make that effort now.
I was a SRE on Gmail, and I can assure you that the experience for devs was not great intentionally. We had a pool of dedicated machines that ran various versions specifically used for development. I made sure those where always on our worst clusters (slowest CPUs and disks) so the dev experience was always the worst case scenario for performance. :-)