Rough idling
tedunangst.com
tedunangst.com
All this was at low priority, so it didn't affect the real time tasks at all. So it wasn't hurting anything. The QNX people were quite embarrassed when we reported this, though.
There are so many things I'd like to fix if I had the time...
Five years ago I was using Chrome and it was fast, lightweight, and stable. Now it's slow, uses 500 MB of RAM, and the renderer crashes on a regular basis.
If people knew that their own choice for speed improvements was optimization (and to a certain extent, that is true already), then they might focus more on that instead of adding features.
1) Your definition of what is fast changes. Downloading an MP3 in 5 minutes felt really fast in 1998, but really slow today.
2) What we expect chrome to do keeps increasing. Since Chrome was so fast, people started creating webpages that had to do more (because they could!) It is a form of Induced Demand (https://en.wikipedia.org/wiki/Induced_demand)
Consider how much extra performance game developers are able to wring out of a console after a few years' experience. If the hardware is absolutely stable, and there's no expectation that it can get faster, then people do make a big effort on software.
I suspect the target response time is what determines how slow things are, not the speed of the hardware. As people have pointed out, hardware has gotten faster and many user interfaces have gotten slower, so it seems more likely that: the target response times have been rising (people tolerate higher response times in exchange for more features or whatever), or people with older and slower computers observe much higher response times than the original target (iphone 3gs vs iphone 5 for a given app, for instance).
Stable hardware solves the second issue at least, but not sure about the first one. I think over time people will notice that everything else responds instantly to touch, and computers should too, so they will start rejecting apps that have a high target response time.
As an example of that, I chose my last monitor by looking at http://www.displaylag.com/ to get the minimum latency there. If other people start caring more about the latency of the things they use, hardware and software developers will prioritize that.
"Innovations in hardware are to give programmers freedom to build shitty software and get away with it."
One time I found the cause of a program that was run at regular intervals and was taking a few minutes to complete running. It would run approximately 42,000 SQL select calls every time it dropped into a new directory to parse some files. It only took 10 minutes to process the entire directory structure. So the program was actually incredibly fast, considering all the work it was doing.
The catch? It only needed to run SQL select 42 times per directory; the other 41,958 calls were not necessary. As far as I know it was never fixed, because it only took 10 minutes to run.
ps: LMGTFM https://en.wikipedia.org/wiki/Kevlin_Henney
Later, wisdom visited me and I realised the costs of `typeof isThisAFunction` and the savings of optimising out an empty function call in the first place.
"I didn't have time to write a short letter, so I wrote a long one instead."
https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...
For example, TCP is so widely used and affects so many machines with each transaction (i.e., the endpoints and everything in between) that I'd guess that a tiny increase could make a large impact globally. Or there might be other software where there's an opportunity for a large improvement.
Never.
Flash Player should be a crime against humanity based on its energy usage alone.
https://www.wind-watch.org/documents/u-s-wind-capacity-facto...
(The average wind turbine capacity factor in the Texas Panhandle is closer to 35% because it's windier there)
I work on stuff that needs to run for years off of small batteries. An issue has been previously just like Windows(tm) all RTOS depended on a heartbeat interrupt. Which means the RTOS wakes up every 1-10ms to check if a timer has expired, see which task should be running, etc. The truth is, 99% of the time there is absolutely nothing to do. Or in my case 99.9% nothing to do.
I've had to roll my own routines to keep track of how long till the next timer expiration and use that set a hardware timer that wakes up the uP. And also for timers that don't require low latency, marshal the events and do them all at once every so often.