bryancall opened a new pull request, #13670:
URL: https://github.com/apache/trafficserver/pull/13670
There was no way to answer "is this faster" or "does this allocate more"
about a change to
the regex wrapper except by writing a throwaway program each time. This adds
a permanent
one.
### What it measures
The corpus is what the tree actually matches: a remap path rule, a host
allowlist, an
extension test, and the crash-guard rule from #5762.
**Time** for compiling, copying, a boolean match, a match with captures both
with a fresh
matches object and a reused one, matching through the shared context and
through a caller
supplied one, a twenty pattern `DFA` scan, and the long subject that drives
a match to the
JIT stack bound.
**Heap allocations** per operation, counted by interposing the system
allocator. PCRE2
makes every allocation for a compile or a match through the callbacks this
wrapper
installs, and those reach the system allocator, so the count covers what the
wrapper
caused rather than only what it asked for directly.
### Results on the current tree
Measured on a Ryzen 9 9950X3D, Fedora 44, gcc 16.2.1, PCRE2 10.47, medians
of three rounds
of 50 samples:
| operation | time | allocations |
|---|---|---|
| bool exec, hit | 25.7 ns | 0 |
| bool exec, miss | 18.3 ns | 0 |
| exec with captures, hit | 25.6 ns | 0 |
| exec with captures, reused matches | 19.8 ns | 0 |
| compile a path pattern | 3017 ns | 6, 8813 bytes |
| copy a compiled pattern | 7.5 ns | 1, 197 bytes |
| DFA match, first of 20 | 26.5 ns | 0 |
| DFA match, last of 20 | 781 ns | 0 |
Two things worth recording. **Matching already reaches the heap zero
times**, because
`RegexMatches` hands the pcre2 general context and match data out of its own
400 byte
buffer; any future change to this class has to preserve that rather than
rediscover it.
And **a copy is 400 times cheaper than a compile**, which is not a free
lunch: see #13666,
where it turns out the copy is cheap because `pcre2_code_copy()` leaves the
just-in-time
machine code behind.
### Notes
- Built only with `-DENABLE_BENCHMARKS=ON`, which is off by default, so this
changes
nothing about a normal build.
- Numbers are reported, not asserted. Block sizes differ between PCRE2
releases, so an
assertion on allocation counts would fail on a version whose match data
does not fit the
inline buffer, which is a fact worth printing rather than a test worth
failing.
- The allocation counters are wired up on Linux, where defining the
allocator symbols in
the executable is enough to interpose them. Elsewhere they report
themselves unavailable
rather than printing zero.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
