It's quite sad to see how we hardly use the computing power offered by our modern computers to actually speed up common tasks, but instead bloat it up with all kinds of stuff.
[1] http://cogsci.stackexchange.com/questions/1664/what-is-the-t...
My desktop takes about two seconds to resume from suspend. I'd sit down, lean down to the floor and press the power button and then wait that two seconds. I fixed the whole problem by moving the case up onto the desk so that I have to walk past it to sit down. Now I press the button and then sit down, by which time the computer is waiting for me. The way it should be.
Sidebar: Now I'm slightly concerned that an AI in the future is going to call me out for my blatant display of meatbag privilege.
We can throw tons of money at engineering boot times but but really the biggest gains are made when you can predict what the user wants. Imagine you approach your car. If it can detect you or your key, it can start doing stuff it'd normally do when you put the key in the ignition. Suddenly it doesn't matter than it takes 5-10 seconds to boot because it also takes 10 seconds to get in the car.
All this stuff is going to get better once we have widespread adoption of technology for fine indoor tracking. When we can tell our relative positions to our gadgets, they'll be able to sleep deeper, ring louder, shine brighter and start booting earlier.
The easiest and safest thing is usually still to let people control more of what happens because there's a lot of edge cases that might add up, or have really bad consequences for when they rarely occur.
Even though it often feels like you do, humans generally don't know their own intents. It's not that high of a bar for a predictive system to clear.
Unless you're going to be repeatedly walking too and from your car all day, starting a computer needlessly isn't going to be the end of the world.
Yes, it may mean doing more work but that's the trade off here for "instant on". It's either always on, you wait, or it guesses when you're going to use it and you accept there are a few false positives.
Or engineers reduce startup time to a point where it feels instant.
Compare e.g. startup times of DSLRs and point-n-shoot cameras. With a DSLR you switch it on and it is ready to shoot by the time your finger gets to shutter button.
It's also very hard to engineer a boot time down. TFA is a great example of that. Hard means expertise and time and (often) more expensive hardware. So to boil it right down with my car computer example, it's far easier and cheaper to detect the key externally and boot earlier than it is to strip a 10 second boot time down to 0.1 second.
If you can also use that getting-in-the-car time to do other stuff (lookup up recent searches or upcoming appointments and suggesting navigation, setting fuel waypoints if low, getting traffic advice, etc), that's all the better.
And it's actually even worse than that. 100ms is nowhere near enough to be sufficient for all applications.
For audio applications you need 10ms [http://superpowered.com/androidaudiopathlatency] which incidentally is the reason why Android is unusable for any interactive audio applications.
Same applies to Virtual Reality. You need sub 20ms latency for head tracking to eyes latency or you will feel sick (effectively less than 10ms from the cpu side. Display scanning is summed on top).
The 100ms figure applies mostly to traditional UI workflow. Whenever you need a realtime interaction that's 10x too high.
Everybody says this and yet programs like Caustic seem to do a fine job in my experience.
There's a great explanation here as to why it's so bad: http://superpowered.com/androidaudiopathlatency
There are also indications that they are going to lower the display path latency, which also stands several times higher than what is in iDevices. It just takes some time to get a certain class of software architects to realize that buffering a frame several times each step might not be the smartest way after all.
Strange. The primary use of my (Android) phone is interactive audio. I do not recognize latency as an issue.
FWIW, if you are playing virtual drums, drummers need something like under 2ms response time; even 10ms can be easily felt by a drummer and cause their timing to get way off!
On top of that, if you are doing, say, a real-time effect on a vocal track, even a tiny sub 1ms delay causes a weird reverb effect in her monitor vs. the singer hearing herself, which will cause your singer's singing to get out of sync!
Also, for devices that require user authentication, such as logging in to an account, if you could offload the authentication (such as fingerprint or other biometrics) to something out of the OS itself (ROM routine that starts up with a 0 in a certain memory address and changes it to 1 on authentication), you could be booting up the OS in the background while you take a second or two to log in, and if the OS can get up and running by the time you log in, the OS can pretend that it started up immediately and was the thing that logged you in. For many devices, there is need to boot up in less than a second or so to seem as though boot up was instantaneous.