One more point occurs to me. This is that the techniques in my book are primarily based around using functions. If the techniques are slower than other techniques, it is probably because they call a lot of functions. If function calls are slow, that is not a problem with the techniques; it is a problem with the language implementation.

I don't really agree with this. I mean, yes, if slow function calls are a problem then yes it is a language issue that really long term aught to be handled by fixing the implementation. But on the other hand we are engineers and problem solvers that have to work with the tools we have. So assuming that we have good reasons to use Perl, and assuming that functions are a problem then any technique that depends on them heavily is flawed in some situations when using the Perls that are available right now.

Personally im in the camp that says that for some tasks Perl's method overhead and subroutine overhead becomes unacceptable. That may be because of the type of work I do (reasonably large scale data processing), but thats the way I view it. Now, what I think is really interesting are the techniques that allow you to have your cake and eat it too. So for instance I've found that constructing tailored code that doesnt use subroutine or method calls from a rule set implemented in OO is quite powerful. Each rule knows how to represent itself as a snippet, and once the rules are stiched together you get a single monolithic piece of code that performs very well. At the same time you get a clean conceptual model that you can work with at a higher level of abstraction.

Anyway, I was hoping that HOP had stuff along this line but your response makes me think not. Nevertheless I still look forward to reading it. :-)