调用C库本质是让代码脱离Python解释器运行以绕过GIL并减少对象操作开销，但性能提升取决于调用频次、数据规模及数据传递方式，ctypes/cffi/Cython在封送开销上差异显著。
因为Python解释器的执行模型和C语言的执行模型存在根本性差异，调用C库不是“加速Python”，而是让部分代码彻底脱离Python解释器运行。
CPython的GIL锁让多线程CPU密集任务无法并行
CPython中，GIL强制同一时刻只有一个线程执行Python字节码。即使你启用了4个线程跑纯Python循环，实际仍是串行执行——CPU利用率不会显著提升。
- 你在C函数里做的计算不经过
GIL检查，只要不调用Python C API（如PyList_Append），就天然绕过GIL - 若C函数内部用
pthread或OpenMP做并行，就能真正吃满多核 - 注意：用
ctypes加载的C函数默认不释放GIL，需手动调用Py_BEGIN_ALLOW_THREADS（仅限原生C扩展）
Python对象操作开销远高于C的原始内存访问
每次arr[i] += 1在Python中要查类型、查边界、更新引用计数、可能触发GC；而C里就是一条mov加一条add指令。
- 动态类型意味着每次运算都要走类型分发逻辑，C直接按
int*指针算地址偏移 - Python列表是对象数组，
list[i]本质是解引用+类型检查；C数组是连续内存块，arr[i]就是base + i * sizeof(int) - 高频调用时，哪怕单次开销只差10ns，100万次就是10ms——这正是
ctypes调用fast_sum比Python循环快7倍的主因
ctypes/cffi/Cython三者在数据传递上性能差距极大
不是所有“调C”都一样快。性能瓶颈常卡在Python和C之间的数据搬运环节，而非C函数本身。
立即学习“Python免费学习笔记（深入）”；
-
ctypes：每次调用都要把Python对象封送成C类型，arr.ctypes.data_as(...)看似零拷贝，但argtypes声明错误会导致静默转成临时副本 -
cffi：支持cdef提前定义接口，封送开销略低于ctypes，且能更安全地处理复杂结构体 -
Cython：编译期生成C代码，可直接用memoryview或np.ndarray传参，避免封送，是三者中数据传递最高效的方式
真正容易被忽略的是：C扩展的收益高度依赖调用频次与数据规模。一个只被调用一次、处理10个数的C函数，可能比纯Python还慢——启动共享库、解析符号、封送参数的成本已经覆盖了计算收益。必须确保C侧工作量远大于跨语言调用开销，否则就是在给解释器打工。
