1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fixed censorString & broken fast path for no censoring.

Discussion in 'Resolved Bug Reports' started by Xon, Jun 4, 2014.

  1. Xon

    Xon Well-Known Member

    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
  2. Mike

    Mike XenForo Developer Staff Member

    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).
  3. Xon

    Xon Well-Known Member

    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.

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

Share This Page