Fixed censorString & broken fast path for no censoring.

[Xon]

Inside the censorString there is a fast-path check to return early if there are no censoring to apply and thus avoid the preg_replace call.

However, it appears that the line:

$string = preg_replace(array_keys($censorCache), $censorCache, $string);

Will be called when $censorCache has no contents in some cases, which I observed using xdebug trying to track down why a thread was taking considerable time to render.

It also appears that this preg_replace call is not a no-op when passed a zero length array as it was taking a ~10% of the execution time for rendering a thread

 

[Mike]

Only calling that if there is a $censorCache value.

Looking at the C behind this, it looks like it should mostly be a noop. There's no optimization to skip an empty array, but the only work I see it doing should be zval prep, which is of course useless and if you have a huge string I suppose it could be non-trivial (since it looks like it does copy the string).

 

[Xon]

Only calling that if there is a $censorCache value.

I'm fairly sure that this only applies on the first call to censorString for the request, and as I understand it this function can be called once per post contents in a thread (via censorStringTemplateHelper).

On the First call to censorString with $words = null & $censorString = null; $censorCache is null and a new entry is built which can be an empty array for a could of reasons.

On the second call to censorString with $words = null & $censorString = null; it detects that $censorCache is not null and invokes preg_replace.

Looking at the C behind this, it looks like it should mostly be a noop. There's no optimization to skip an empty array, but the only work I see it doing should be zval prep, which is of course useless and if you have a huge string I suppose it could be non-trivial (since it looks like it does copy the string).

Yes, my forum has to deal with large posts quite often. Literally novels in some threads with crazy amounts of formatting.