基于Plan9 rune API的C Unicode库：大查找表与.rodata段疑问

我正在基于Plan9 libc的rune API编写一个简易C语言Unicode字符库，初衷是学习Unicode，但后续会用到自己的其他项目中。目前项目最复杂的部分是字符数据处理，最初的草稿实现是利用Unicode码点连续的特性，将同类字符类型的起始、结束码点提取后存入表格。但阅读Unicode规范第5章第1.2节的实现部分时，看到这段内容：

范围优化的误区：你可能会想通过嵌套范围或类似手段来“优化”这些表格的空间占用，但这种做法在现代高流水线架构的处理器上会带来不必要的性能损耗——因为分支惩罚。更快的方案是使用优化的两级表，这种实现不需要任何测试或分支指令。哈希表也能用来优化空间，但速度不如多级表。

规范指出我的初始方案存在性能问题，更高效的实现方式是扁平查找表或多级查找表。我之前觉得直接做一个大表太过简单，但实际它比当前的范围表实现要简便得多，现在有两个疑问：

问题1：多大的查找表会被共享/静态库视为“过大”？ #

没有绝对的数值标准，核心看应用场景：

• 静态库：静态库会被直接链接进可执行文件，表的大小会直接影响最终程序体积。如果目标是嵌入式设备（比如闪存只有几十KB的MCU），几KB的表可能就属于过大；但在桌面或服务器环境，几十甚至上百KB的表都完全可控——毕竟现在普通程序的资源文件动辄几MB。
• 共享库：共享库的.rodata段在运行时会被加载到内存，且多个进程可共享同一份映射。一般来说，只要表的大小不超过几MB，都不会有明显问题；但如果表大到几十MB级别，会拖慢库的加载速度，在内存紧张的环境中还可能被系统换出到swap，导致访问延迟升高。

另外还要考虑你的用户群体：如果是给轻量工具用的库，大表会增加分发体积；如果是给性能敏感的服务用，空间换时间的权衡是合理的。

问题2：现代CPU上，库中存在大型.rodata段有什么弊端？ #

主要有三点，但都是在表达到一定规模后才会显现：

• 启动加载延迟：如果.rodata段过大，库加载时需要从磁盘读取更多数据，会拖慢程序启动速度——机械硬盘环境下这个影响尤为明显，SSD则会缓解很多。
• 内存占用压力：虽然共享库的.rodata可被多进程共享，但如果只有少数进程使用该库，大表仍会占用不少物理内存。在内存资源紧张的场景（如容器、嵌入式设备）中，可能会挤压其他程序的内存空间。
• 缓存命中率下降：现代CPU的L1/L2/L3缓存容量有限，如果大表无法被完全容纳进缓存，每次访问表都会触发缓存miss，反而降低性能——这和用大表换性能的初衷相悖。比如几十MB的表根本不可能放进L3缓存，每次访问都要从主存读取，延迟会大幅上升。

如果你的表大小在几KB到几十KB级别，现代CPU的缓存完全能容纳，基本不会有上述问题。

内容的提问来源于stack exchange，提问作者Zeno of Elea