为何带缓存的print_columns函数运行速度反而慢于无缓存版本？

核心结论 #

这种情况主要是缓存的开销远大于计算本身的成本，同时当前基于Perl HV哈希表的缓存实现存在过重的性能损耗，而非场景完全不适合缓存。

具体原因分析 #

1. _char_width本身的计算成本极低

如果_char_width只是做简单的查表、范围判断或位运算（比如Unicode字符宽度的常规实现：通过码点范围判断半角/全角，或者查预定义的静态数组），单次计算的耗时可能只有几纳秒。而Perl的HV哈希表是Perl层面的复杂结构，XS中操作HV的hv_fetch/hv_store函数需要处理哈希值计算、桶遍历、SV引用计数维护、甚至哈希表扩容逻辑，这些操作的单次开销远高于直接计算字符宽度。

2. 基于Perl HV的缓存实现开销过重

在XS里用Perl HV做缓存，会额外引入多个性能损耗点：

• 键的生成成本：要把单个字符的码点转换成Perl的SV作为哈希键，需要调用newSViv/newSVpv等函数创建SV对象，这一步的开销可能比_char_width的计算还大。
• HV的内部操作开销：Perl HV不是纯C的轻量哈希表，它要兼容Perl的动态特性（比如自动扩容、线程安全、引用计数），这些特性都会带来额外的性能成本，哪怕是单线程场景也无法避免。
• 缓存操作的冗余步骤：比如每次缓存命中/未命中时的SV类型检查、引用计数增减，这些步骤都会累加耗时。

3. 缓存命中率不是核心问题

你测试的是重复字符（全是🙂），缓存命中率是100%，但性能依然更差，说明不是命中率的问题——哪怕每次都能命中，HV的查找开销还是比直接计算大。

验证与优化方向 #

• 量化开销对比：在XS里加计时逻辑，分别统计单次_char_width调用、单次HV缓存查找+存储的耗时，直接对比两者的开销差距。
• 换用轻量缓存结构：如果一定要缓存，不要用Perl HV，改用纯C的轻量缓存：
  • 若字符码点范围可控（比如只处理BMP字符），直接用静态数组，索引就是字符码点，O(1)访问且无额外开销。
  • 用C语言的轻量哈希库（比如khash.h），避免Perl HV的额外损耗。
• 直接移除缓存：既然_char_width本身足够快，缓存完全没有存在的必要，直接调用反而性能最优。

内容的提问来源于stack exchange，提问作者sid_com