[engendered]

Is this legitimately a bug, though? It could be tagged as a performance defect, but there is code like this through projects across the land.

I think the reason this rubs some people the wrong way is that implementations like this can be the result of the "no premature optimizations!" philosophy and its advocacy. I've encountered this firsthand at a number of organizations, and it apparently was somewhat endemic in the Ruby space.

Make something that works, and benchmark later to find that one magical hog that you can quickly change and then everything is optimal. Only it almost always ends up being a performance death by a thousand (million) cuts, performance and resource malaise so endemic that fixing it almost seems impossible.

[nirvdrum]

Not to get all philosophical, but "legitimately a bug" is a hard question to answer. Some people strictly consider correctness to be the definition of a bug. Others extend the definition to mean when things don't work the way they probably should (e.g., performance or usability). Performance is an especially interesting one to me because if it's not really a bug, then does a performance regression constitute a bug even if it's producing the same results? If someone is relying on that timing or it otherwise affects interaction with the code, its execution speed is a functional component.

In my experience, projects that adopt a slightly broader definition of "bug" have a better track record of improving on those fronts. Nobody like to have bugs around, after all.