升级至CGAL-5.3并切换64位环境后2D几何运算性能下降问题咨询

1. Boost Pool 版本差异与配置验证 #

• 对比Boost1.64和1.77版本boost::pool的默认参数变化：重点检查 块大小默认配置、对齐规则、内存碎片回收阈值 这三项，64位架构下指针长度翻倍，原有32位下适配的pool块大小可能出现大量内存浪费或频繁扩容
• 验证CGAL 5.3是否修改了2D几何模块的内存分配器绑定逻辑：CGAL 5.x开始大量默认切换为std::allocator，部分场景下会fallback到boost pool但参数未做64位适配，可通过宏CGAL_USE_BOOST_POOL强制开启/关闭对比性能差异
• 测试关闭pool线程安全选项：如果业务为单线程场景，编译时定义BOOST_POOL_NO_MT关闭内部锁开销，64位下原子操作开销比32位高30%~50%是常见现象

2. 32位转64位的内存行为适配验证 #

• 统计2D几何对象的平均大小：64位下CGAL的几何内核（如Cartesian内核）的坐标类型如果还是用double的话对象大小会增长30%以上，原有pool的块大小如果是按32位对象大小配置的，会出现单块只能存1个对象的情况，完全失去pool的复用优势
• 检测内存碎片率：用malloc_stats()（glibc）或对应平台的内存统计工具，对比升级前后的arena占用和实际使用内存的比值，如果比值超过3，说明pool的内存复用效率极低
• 验证大页适配：64位系统默认开启透明大页（THP）的情况下，pool的小块内存分配可能触发大页拆分，产生额外开销，可临时关闭THP测试性能变化

3. 基准测试隔离验证 #

• 单独编译CGAL 2D几何的最小用例：仅保留多边形裁剪、三角化等核心业务用到的能力，分别用旧版本依赖+32位、新版本依赖+64位编译运行，隔离业务代码的影响
• 替换内存分配器对比：用tcmalloc/jemalloc替换默认glibc分配器，同时关闭boost pool，测试性能变化，如果性能恢复说明确实是pool的分配逻辑问题，如果无变化则需要排查CGAL 5.3的2D算法变更（部分2D算法在5.x版本为了支持并行做了额外的同步开销，单线程场景下会出现性能下降）

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