i think that part of the issue is that these problems are so far down the optimization stack at this point, that they are seen as late optimizations.
development should start simple, and problems should be solved as they become apparent. to do otherwise would be counter-productive.
imagine how complex development of a text editor would be if we assumed that we had such major constraints? at this point, it is good to revisit some of those optimization, as we strive for small improvements, but to entertain going all the way to bare metal is just ludicrous.
while i am grateful for the knowledge from such resource-driven development (i did that too, writing video games for 286/386 and 68040 we were quite restraint-driven), i am happy that we can think of these sorts of optimizations as further down the pipeline optimizations, and don't need to consider them day to day.
development should start simple, and problems should be solved as they become apparent. to do otherwise would be counter-productive.
imagine how complex development of a text editor would be if we assumed that we had such major constraints? at this point, it is good to revisit some of those optimization, as we strive for small improvements, but to entertain going all the way to bare metal is just ludicrous.
while i am grateful for the knowledge from such resource-driven development (i did that too, writing video games for 286/386 and 68040 we were quite restraint-driven), i am happy that we can think of these sorts of optimizations as further down the pipeline optimizations, and don't need to consider them day to day.