> 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
