From the measurements I did today, I am pretty sure that checking those conditions will be slower than just doing the preg-repace.
From the numbers output by the test script (basically time in seconds to call s() 40000 times) I think the scores were very roughly:
1. Any PHP function call: 0.4
2. htmlspecialchars: 0.6
3. preg_replace: 1.0
4. simplifying the if: 0.1
5. removing the default arguments to htmlspecialchars: 0.1 each.
There was actually a lot of noise on top of that, but I ran the test script many times.
I wish we had documented why the preg_replace was necessary at all. I would actually be inclined to make things slower, by adding debugging logic so that any time the preg_replace did something, it displayed a warning. I can't think of a good reason why we want s('
') to be '
' and not '
'. Do you remember.
Anyway, I have spent all the time I can afford on this. I think I have made things better, so I should submit this for integration. If you want to try and squeeze more performance out here, then we can create a new issue.
(But, if you want to optimise something, then the load testing results I saw today were, for a course view page:
mostly it was DB and MUC, of course. I hope the people doing our load-testing will summarise what they learned in a forum post.)