Here's a little old fart story from more than 25 years ago.
We'd been working on a hardware product and put a fair bit of effort into optimizing something that had to be done 1M times at startup, getting it down to a few seconds, in theory.
Software comes to complain that it's grossly inefficient and takes forever. Investigate. Well. They're running a 1M iteration loop and then calling down through something like a dozen layers of object oriented subroutines, constructors and destructors and all, to execute the hardware primitive, one at a time.
So I crack the PowerPC (this is ancient history, remember) manual and write a bit of assembly language. See here, I can get it done in 2.5 seconds!
That's ridiculous! We can't block for 2.5 seconds in a subroutine call.
Well how long can you? Oh. Well, then call it 100 times and do 10K iterations each time. So they did that, and problem solved.
That's because we still had full-stack expertise. Everything was in house.
These days, complexity is so vast that you simply can't afford to own the full stack any more. And so gross inefficiencies like the above creep in and there's simply nobody around to understand, much less fix them.
The same thing is briefly alluded to in my brother's video about the early days at Research in Motion (https://youtu.be/GLxjXP-XCJA). Talk about full stack. He spent a huge amount of time just working out how to extract every last millijoule out of an alkaline AA cell. And stopping software developers from introducing inefficiencies like the above. Full stack! And the RIM 950 really was an awesome gadget, running, if I recall correctly, for two weeks on that measly AA battery. Simply not possible if you're just bolting together re-usable pieces from different sources.
We'd been working on a hardware product and put a fair bit of effort into optimizing something that had to be done 1M times at startup, getting it down to a few seconds, in theory.
Software comes to complain that it's grossly inefficient and takes forever. Investigate. Well. They're running a 1M iteration loop and then calling down through something like a dozen layers of object oriented subroutines, constructors and destructors and all, to execute the hardware primitive, one at a time.
So I crack the PowerPC (this is ancient history, remember) manual and write a bit of assembly language. See here, I can get it done in 2.5 seconds!
That's ridiculous! We can't block for 2.5 seconds in a subroutine call.
Well how long can you? Oh. Well, then call it 100 times and do 10K iterations each time. So they did that, and problem solved.
That's because we still had full-stack expertise. Everything was in house.
These days, complexity is so vast that you simply can't afford to own the full stack any more. And so gross inefficiencies like the above creep in and there's simply nobody around to understand, much less fix them.
The same thing is briefly alluded to in my brother's video about the early days at Research in Motion (https://youtu.be/GLxjXP-XCJA). Talk about full stack. He spent a huge amount of time just working out how to extract every last millijoule out of an alkaline AA cell. And stopping software developers from introducing inefficiencies like the above. Full stack! And the RIM 950 really was an awesome gadget, running, if I recall correctly, for two weeks on that measly AA battery. Simply not possible if you're just bolting together re-usable pieces from different sources.