Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104831
MIME-Version: 1.0
References: <CAK5kH3x-P+eDXtf0wsm-=sffMq6y_6QGAdavikMEOGu=R1ddeA@mail.gmail.com>
 <CAK5kH3zGox7e9o3NhQav2hutk3hZoKAeXPkH7dNK9+aSDmbemw@mail.gmail.com>
 <CAF+90c89oR5OhC6ihAiSrQZtPfCEUStevKp8jg00HVE1gcpKDg@mail.gmail.com> <CAF+90c_0+eDvxuNi1NyMN=K39MtaNH7qXV=WrH5D0CB943VJng@mail.gmail.com>
In-Reply-To: <CAF+90c_0+eDvxuNi1NyMN=K39MtaNH7qXV=WrH5D0CB943VJng@mail.gmail.com>
Date: Wed, 20 Mar 2019 11:35:07 -0400
Message-ID: <CAK5kH3xk=xNR2+5McWVaOfo9_MRS=JydTpraSB1DpQXNjkvGUQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007356c60584885e0b"
Subject: Re: [PHP-DEV] Offset-only results from preg_match
From: cananian@wikimedia.org ("C. Scott Ananian")

--0000000000007356c60584885e0b
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 19, 2019 at 10:58 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> After thinking about this some more, while this may be a minor performance
> improvement, it still does more work than necessary. In particular the use
> of OFFSET_CAPTURE (which would be pretty much required here) needs one new
> two-element array for each subpattern. If the captured strings are short,
> this is where the main cost is going to be.
>

The primary use of this feature is when the captured strings are *long*, as
that's when we most want to avoid copying a substring.


> I'm wondering if we shouldn't consider a new object oriented API for PCRE
> which can return a match object where subpattern positions and contents can
> be queried via method calls, so you only pay for the parts that you do
> access.
>

Seems like this is letting the perfect be the enemy of the good.  The
LENGTH_CAPTURE significantly reduces allocation for long match strings, and
it allocates the same two-element arrays that OFFSET_CAPTURE would -- it
just stores an integer where there would otherwise be an expensive
substring.  Furthermore, since the array structure is left mostly alone, it
would be not-too-hard to support earlier-PHP versions, with something like:

$hasLengthCapture = defined('PREG_LENGTH_CAPTURE') ? PREG_LENGTH_CAPTURE :
0;
$r = preg_match($pat, $sub, $m, PREG_OFFSET_CAPTURE | $hasLengthCapture);
$matchOneLength = $hasLengthCapture ? $m[1][0] : strlen($m[1][0]);
$matchOneOffset = $m[1][1];

If you introduce a whole new OO accessor object, it starts becoming very
hard to write backward-compatible code.
 --scott

--0000000000007356c60584885e0b--