Wedge

Yup, even though it's only tracking what a user is doing 'right now', it's still got a privacy concern attached.

But just for fun, and in defence of the thing I keep arguing in favour of, the number of guests now becomes hilariously inaccurate now, as feline indicated 70% or so of guests don't agree to the ECL thing, in which case the number of guests reported is probably only 30% of the number of actual guests... so why bother keeping it?

I don't think that'll make much difference, really. It's all pure CPU (excluding Aeva and media processing) so all you'll be doing is establishing the relative performance of each server.

I don't believe anyone's really done external tests.

So, I've been watching this for a while, ever since I heard that PHP 5.4 would deprecate call-time pass-by-reference, knowing full well that both SMF and Wedge's hook caller uses this.

I was not surprised to discover there were issues, nor was I surprised to note what the issues were, and now that I think about it, I was not surprised to note that my observation was entirely correct.

OK, here's the deal. When a hook is called, normally all the variables are shoved through call_user_func_array by reference. As of PHP 5.4, that won't work as expected.

Specifically, it won't work if the receiving function's signature doesn't state it's expecting things as references. Which meant that most of the mods written using hooks actually didn't work properly under PHP 5.4, though oddly enough this was never an issue for mine, because I always indicated everything should be by-reference anyway in the signatures, I found it a good practice to get into.

What that also means we should probably strip all the & signs from call_hook calls, because in both 5.3 and 5.4, the function's signature should be indicative of receiving-by-reference and in both cases it should be honoured.

In any case, any plugin using hooks should note that all variables received, that are intended to be modified in place should be indicated in the function xyz() definition as function xyz(&$variable) not function xyz($variable).

Hrm, interesting. I know that there were already slight changes made (e.g. about how the tag list was built)

I'm just surprised that you're not seeing as much load.

Aeva and media have specific reasons why they make a significant difference. For general parsing, it's just a case of having very long posts with lots and lots of tags.

If the strlen changes make it faster, I'm all for keeping it. Just nudge me to make sure the bbcode support in the plugin manager does it too.

Don't forget places like PhotoBucket that provide 'embed code', only for it to be in uppercase.

The reason, ultimately, that parse_bbc is slow is not because of lacking micro-optimisations but because of its overall methodology, where it steps through the content tag by tag. Posts that aren't tag heavy will be quick, posts that have lots and lots of tags will be much higher proportionately.