The "underlying mechanisms" go pretty deep. You seem to be making reference to the implementation of Perl, in C, but there are mechanisms underlying that too. Should one also understand the underlying mechanisms of the C compiler? There's the OS. There's the hardware. There's physical science that explains how the hardware works.

That's one of the things that makes programming a science and art: you have to know which abstraction levels you care about.

To decide that, you have to know them, at least most of them a little bit.

Let's stay at the regex example: if you do more than just very simple regexes, you have to know that perl's regex engine is a NFA (which means the order of alternations is important), and that it matches greedy by default.

It also helps to know that all kind of anchoring results in a performance benefit.

For some programmers that might be enough to know, for others it isn't.

Suppose you decide for a larger team which of the regex best practices you apply. In that case I think that you should know more about implementation and optimzations.

If you just decide for yourself, then you don't need to know more, but you shouldn't complain about slow regexes when you don't.

Every attempt to say "I'll inform myself until I reach abstraction level $x, and then no more" is bound to fail at some point, and your curiosity should prevent you from stopping at one level ;-)

I agree that most micro-optimizations are not worth having, but runtime differences of two orders of magnitudes are worth noting nonetheless.

Readability shouldn't suffer, so perhaps I should write my regexes as my $space = " "; m/... $space/; or use the \N notation.

IMHO sticking to best practices without understanding them makes coding something mechanical, and poses the risk of cargo cult programming.

My view might be influenced by the fact that programming is mostly a hobby for me, and I want to be fun above all else, and apart from this forum most code that I maintain is my own.