为何处理字符串元组时Numba性能比原生Python慢100倍？

以下是导致你测试结果出现100倍性能差距的核心原因：

• 编译开销被计入测试统计
  numba采用懒加载的即时编译（JIT）机制，第一次调用被@jit装饰的函数时才会将代码编译为机器码，这个编译过程的开销极高。你在执行timeit时直接运行未编译的numba函数，将编译时间也计入了总耗时，对于仅运行20万次、单次执行耗时极短的轻量函数来说，编译开销占比被无限放大。
  你可以在执行性能测试前先手动调用一次get_exact_score_with_numba(tokens_to_match, candidate_tokens)触发编译，再运行timeit，总耗时会大幅下降，但依然会高于原生Python，这是由第二个原因导致的。
• 应用场景不匹配，numba字符串操作优化弱于CPython原生
  你当前的函数核心逻辑是字符串元组的in成员检查，这类操作CPython本身已经是高度优化的C语言实现，执行效率极高。而numba的优化优势集中在数值类的计算密集型循环，对字符串、字符串容器的成员判断并没有做针对性优化，甚至需要额外处理类型适配、边界检查等逻辑，执行效率反而低于CPython原生实现。
• 函数负载过轻，调用开销占比过高
  你当前的测试用例中tokens_to_match长度仅为2，单次函数执行仅需要2次循环和2次成员判断，本身耗时极短。而numba函数调用时需要做Python对象和numba内部类型的转换、参数类型校验等额外固定开销，这些开销在总耗时中的占比远高于函数本身的计算开销，进一步放大了性能差距。

验证提示：如果将逻辑替换为数值数组的数值计算/成员判断，同时放大输入规模（比如tokens_to_match长度提升到1000以上），提前触发编译后再测试，numba的性能就会明显超过原生Python。

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