We rely a lot on hardware, tools or software optimizing automatically. We expect it from processors, compilers, databases, javaspaces, caches and so on.
But there’s a limit to what can be achieved because these elements can only make a best guess at what we are trying to achieve and optimize on that basis.
These guesses are based on limited context - e.g. an instruction stream or the recency and/or frequency with which something is updated. The big picture as to what’s really going on is in the surrounding application or maybe even just the programmers head.
Thus without programmer involvement, there’s always a limit to what we can deduce from limited contextual information. The problems come when our systems can’t deduce enough to be effective in their optimization. This can happen because there isn’t enough information (it may have been removed or was never present) or more interestingly because the programmer writes code that isn’t amenable to the optimization process.
Thus it is quite interesting that we spend much time hiding details like concurrency or distribution from our programmers (via frameworks or tools) actually preventing or at minimum discouraging them from getting involved in and specifying the necessary details to optimize effectively.
Technorati Tags: architecture, design, distributed systems, performance
Entries (RSS)