There's premature optimisation, where you write a whole bunch of complicated code to avoid cloning an Arc<>. And then there's "premature optimisation" where you skip any consideration for performance until it becomes a problem.

The latter is usually what people who use the quote "premature optimisation is the root of all evil" think it means. Don't just keep calm and clone, consider what you're cloning and why, and then hopefully we won't end up with even more horribly slow software.

▲

bananamogul an hour ago | parent | next [-]

Isn’t the latter what Knuth meant?

Such a slippery slope between “consideration of performance” and optimization.

	▲	cogman10 4 minutes ago \| parent [-]
		The full quote > Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. Notice the aspects and the reasons for knuth's "premature optimization". Is it making the code harder to debug and read? Is it a non-critical path? If an optimization doesn't impact readability or debugability (for example, picking a datastructure that fits the problem instead of just using a List for everything). Then you should do it. I see the quote so often pulled by people that want to justify inserting a n^2 algorithm when a log(n) solution is either the same amount of code or 1 line extra. There's also important context about the era knuth was programming in. Optimization in the era of knuth was targeting the hardware and tickling things like the CPU cache and memory in a very specific way. It was things like clever bit manipulation and packing to save memory. That's the context. In modern terms it'd be "don't use SIMD intrinsics until you know you need them". It wouldn't be "Don't think about algorithmic complexity" which is where I most often see that kludge deployed.

▲

afdbcreid 2 hours ago | parent | prev | next [-]

"Keep calm and clone" is a good advice for beginners. Then it is also a good advice for experts - because when you're an expert and you just think of cloning, that probably means it is easier than borrowing which you would default to.

▲

JoshTriplett an hour ago | parent | prev [-]

By all means use borrowing if it's straightforward. But don't necessarily upend your whole codebase to avoid one clone, either.