running PHP-Parser over laravell shows some perf bottleneck

[staabm]

in https://github.com/TomasVotruba/php-parser-speed-comparison-2026 there is a benchmark, which effictively installs laravel, removes some non-php files and parses all remaining 15961 PHP files (with the goal to compare different php parsers perf wise).

running the nikic/php-parser case thru blackfire reveals a interessting bottleneck:

• String_::fromString()

see blackfire profile (link will be dead in 30 days I guess)

maybe there is something we can do about it

---

another interesting call is PHP8::getAttributes(), but I feel there is not much we can do about that

(maybe this method can be finalized in a future release, so we could inline its code within initReduceCallbacks)

---

this one is also interesting: maybe we can "inline these" PhpVersion specific calls, as the PHPVersion cannot change while parsing

[hiSandog]

Because the hosted profile expires, exporting a stable call summary and recording PHP version, parser version, opcache/JIT settings, hardware, and corpus commit would make the result reproducible. A focused microbenchmark for String_::fromString() across representative literal lengths and escape patterns can show whether an optimization matters outside this Laravel corpus. Please also report its percentage of total wall time before trading readability for a local speedup.

[nikic]

It may be possible to optimize string parsing with a fast path that checks for presence of \. If there are no backslashes, there is nothing to parse.