Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split pcre cache into permanent and per-request caches #4004

Closed
wants to merge 1 commit into from

Conversation

cscott
Copy link
Contributor

@cscott cscott commented Mar 28, 2019

In addition to the permanent pcre cache, maintain a separate per-request cache so that we can use string identity comparisons instead of having to do full zend_string_equal_content() on every cache fetch -- this can be quite costly if the regular expression is large.

This is an alternative to PR #3994 and could be considered a follow-up to PR #3985.

Uses the pcre_cache_entry refcount field to ensure that the permanent cache isn't cleaned while there is still a pointer to the entry in the request cache, but this cleaning mechanism could be further tuned.

@krakjoe
Copy link
Member

krakjoe commented May 25, 2019

@cscott could you fix the merge conflicts please ?

@cmb69
Copy link
Contributor

cmb69 commented Jun 12, 2019

@cscott, any news?

In addition to the permanent pcre cache, maintain a separate per-request
cache so that we can use string identity comparisons instead of having
to do full zend_string_equal_content() on every cache fetch -- this can
be quite costly if the regular expression is large.
@cscott
Copy link
Contributor Author

cscott commented Jun 12, 2019

Required conflict resolution after e06836a was merged, but the changes required were straightforward.

@cscott
Copy link
Contributor Author

cscott commented Jul 2, 2019

Still waiting on review. The test failure above appears to be spurious ("Bug #72333: fwrite() on non-blocking SSL sockets doesn't work [C:\projects\php-src\ext\openssl\tests\bug72333.phpt]" which has nothing to do with this patch as far as I can tell).

@dstogov
Copy link
Member

dstogov commented Jul 4, 2019

@cscott @nikic This patch may make improvement only for some particular cases, when during single request, some regular expression string is constructed and then used many times. In other cases, for example, when regular expression string is reconstructed, the patch only makes slowdown because of additional overhead. In current state, I see slight "slowdown" on WordPress. Probably, this overhead may be reduced. I'll try to think a bit more about this problem.

@scott could you provide a benchmark script, for the case you are optimizing.

@iluuu1994
Copy link
Member

Closing as this has gone stale. Please reopen if you'd like to pick this back up with some benchmarks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants