"Devon H. O'Dell" <[email protected]> writes: > determine where a node is placed is *not* cheap. In the end, an > optimization that slows things down is not an optimization at all. You
There are many different kinds of optimization one can perform. One may optimize compiled code for size, speed, simplicity, or reliability. One may optimize communications for throughput, latency, reliability, or bandwidth efficiency. Operations may be optimized to peform within guaranteed constraints, such as with real-time applications, bandwith contracting, etc. Very often, optimizing for one property sacrifices optimization in one or more of the others. For example, code optimized for speed may occupy more memory; code optimized for simplicity may run more slowly; etc. Which optimization (implementation) is chosen for a particular application depends on the intended use of the application. Ultimately, the resultant properties of the application should be reflected in its documentation. If an app like rsync is intended for -- and good at -- synchronizing files, but not as fast as wget for copying them, it would only be appropriate for rsync's documentation to indicate that design assumption. That way, the user can choose the application with the desired properties for the job. It's not possible simply to "optimize" code. It always has to be optimized for some specific set of intended uses. The design of a protocol (such as 9P) for a certain set of circumstances entails that it will perform better under some circumstances than others. -- +---------------------------------------------------------------+ |E-Mail: [email protected] PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+
