| Newsgroups |
gmane.comp.php.devel |
| Message-ID |
<AMBP191MB2886A7B986F78B3811A8EED0CEAD2@AMBP191MB2886.EURP191.PROD.OUTLOOK.COM> |
> Is it important enough to have this memory footprint added to each PHP
> process though?
>
>> About 13.7 KiB of generated tables
It is not added to each process, and I should have been clearer about what
the number is.
The tables are static const arrays, so they land in .rodata. That section
is mapped read-only, and every process started from the same binary maps
the same physical pages. The marginal cost of an additional FPM worker is
page table entries, not the data.
For scale, measured on Ubuntu 24.04 with PHP 8.3.6:
mbstring.so 1,209,216 bytes
of which .rodata 780,276 bytes
php binary 5,784,016 bytes
PHP therefore already carries roughly 760 KiB of read-only Unicode tables
in mbstring alone, for character set conversion. On the source side the
largest single files in php-src are unicode_table_uhc.h at 402 KB,
unicode_table_cns11643.h at 373 KB, unicode_table_jis.h at 308 KB and
unicode_data.h at 267 KB.
13.7 KiB is 1.16 % of mbstring.so and 0.24 % of the php binary.
Two caveats I would rather state than have found.
The 13.7 KiB is a naive figure: sorted uint32 range pairs, 693 ranges for
Start, 807 for Continue, 251 for the NFC quick check, with the profile
subtraction already applied. A two-stage table would be smaller. I have
not measured by how much and would rather not quote a number I have not
measured.
The tables are linked unconditionally, so the footprint does not depend on
whether any file actually uses the declare. For the same reason it does
not scale with the number of processes either.
Runtime cost is a separate question and is zero for ASCII. The first thing
the check does is scan for a byte >= 0x80; an identifier made only of
ASCII returns immediately, which is every identifier in essentially all
existing code.
One clarification for the list, since messages have appeared in this
thread that read as if speaking for the proposal: I am the only person
working on it, none of those replies were coordinated with me, and I would
ask that my own messages be taken as its position.
Regards,
Luca