3 ms·

I agree with this post whole heartedly. Another related issue is the common advice to "not reinvent the wheel" and use standard library routines and algorithm

by tbirdz 12y ago

I agree with this post whole heartedly. Another related issue is the common advice to "not reinvent the wheel" and use standard library routines and algorithm implementations, often stating how unlikely it is that you would be able to code something better than that yourself. However, this is not exactly true. While the authors of these standard routines may be experts in implementations of their favorite data structures and algorithms, they are not experts in the exact needs and requirements of your application. The standard libraries are used by everyone and so they have to balanced to work well in a wide variety of use cases. In order to support this, standard library authors have to make different tradeoffs than what would be optimal for your specific application. While it is true you may not be able to write as good of a generic implementation that would work well in all use cases (yet), it is quite doable to create an implementation that is superior to the standard for just your use case. Of course there are other concerns in doing this, such as testing, maintenance, etc but from a performance point of view the idea that "you couldn't write a better version than the expert's implementation in the standard library" is not really true.

chipsy 12y ago
I think the argument for using libraries is almost always one of solving for "adequate" performance, not best-case. If you want a library you can actually reuse, you're designing it so that it will work in many situations, and when it doesn't, the design should also support copy-pasting some of the code and reworking it to fit the application. Playing "guess the optimization" adds configuration bulk which can negate the ability of the library to actually specialize in this way. There are specialties, of course, where the point of the library is to be a non-trivial, high-performance implementation. Those are designed towards a specific domain, though.
al2o3cr 12y ago
"Of course there are other concerns in doing this, such as testing, maintenance, etc but from a performance point of view the idea that "you couldn't write a better version than the expert's implementation in the standard library" is not really true." Perhaps, but the bigger problem is that usually in order to know you've written the better version, you need to have actually used the library in a use case as close to the real one as possible and MEASURED.

by tbirdz 12y ago

chipsy 12y ago

I think the argument for using libraries is almost always one of solving for "adequate" performance, not best-case. If you want a library you can actually reuse, you're designing it so that it will work in many situations, and when it doesn't, the design should also support copy-pasting some of the code and reworking it to fit the application. Playing "guess the optimization" adds configuration bulk which can negate the ability of the library to actually specialize in this way. There are specialties, of course, where the point of the library is to be a non-trivial, high-performance implementation. Those are designed towards a specific domain, though.

al2o3cr 12y ago

"Of course there are other concerns in doing this, such as testing, maintenance, etc but from a performance point of view the idea that "you couldn't write a better version than the expert's implementation in the standard library" is not really true." Perhaps, but the bigger problem is that usually in order to know you've written the better version, you need to have actually used the library in a use case as close to the real one as possible and MEASURED.