Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98368
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.180 cause and error)
MIME-Version: 1.0
Date: Wed, 1 Mar 2017 16:35:38 +0100
Message-ID: <CADqTB_jx-VxhXV+24=tjHcL0dbqkDMuwQaLrugrB_7wSeeG26g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114edba28d78240549ad1015
Subject: PCRE caching
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a114edba28d78240549ad1015
Content-Type: text/plain; charset=UTF-8

Hey internals,

I was wondering whether or how PCRE regular expression get parsed and
cached, and I found this answer on Stack Overflow:

http://stackoverflow.com/questions/209906/compile-regex-in-php

Do I understand this correctly, that:

1. All regular expressions are hashed and the compiled expression is cached
internally between calls.

2. The /S modifier applies more optimizations during compile, but caching
works the same way.

3. Compiled expressions are not cached between requests.

If so, this seems far from optimal.

Every unique regular expression needs to be compiled during every request,
right?

So with FPM, or with long-running apps, we're missing an opportunity to
optimize by caching between requests.

And with long-running apps, we're caching every dynamic regular expression,
which could harm (memory overhead) more than help.

Ideally, shouldn't we have (like some engines/languages) a switch to enable
caching?

The run-time can't know if a given regular expression is dynamic or static,
can it? It's just a string either way - so without a switch, you're either
committing compiled dynamic expressions to the cache unnecessarily, and/or
missing an opportunity to cache between requests in long-running apps or
under FPM.

I think most apps use quite a lot of regular expression for validation etc.
so maybe there's a missed optimization opportunity here?

Cheers,
  Rasmus Schultz

--001a114edba28d78240549ad1015--