如果你是一家老牌餐厅的老板，后厨里有位勤勤恳恳的老厨师。他手艺不错，但有个“怪癖”：每一道菜，哪怕已经做了一百遍，他都要重新翻开菜谱，一行一行照着做。你暗暗着急——明明配方没变，为什么不能记下来直接做？这时候，一位新主厨递上了简历，他自称“Numba“。他的独门绝技是：只要在菜谱封面贴一张小小的名片，上面写着”@jit”，他就能在第一次做这道菜时把配方彻底记进肌肉里，之后每一次出菜都快如闪电，味道却分毫不差。 这就是 JIT（Just-In-Time，即时编译）的魔法：Python 是那位老厨师，每次执行都要重新解释一行行代码；而 Numba 用一行装饰器 @jit，把数值计算函数“编译”成 CPU 能直接运行的机器码，让循环和矩阵运算迸发出接近 C 语言的速度。你不需要重写代码、不需要换语言，只需要在这道“硬菜”上贴一张卡。但主厨也有短板：他只擅长固定的“数值硬菜”，遇到动态变化的对象和外部库，还是得请老厨师出马。这篇文章，就把这张认证卡背后的门道一次讲清。

岗位关联

学透 Numba JIT，你就能用最小的代码改动，把 Python 数值计算提速几十到上百倍，在机器学习、科学计算、量化分析等场景中获得实打实的性能红利——这是 AI 工程师性价比最高的性能优化技能之一。

目录
  1. 可视化演示
  2. 初识 Numba：一张认证卡，大厨变快厨
  3. 编译原理：主厨的背菜谱功夫
  4. nopython 模式：是全程闭眼，还是中途翻书
  5. 对比 Cython：预制菜工厂 vs 现场记忆派
  6. 适用场景：哪些菜配得上拿手绝活
  7. 使用限制：有些菜，主厨真的做不了
  8. 实战参数：点单技巧，让大厨火力全开
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Numba @jit装饰器的JIT编译流程、与Cython等工具的性能对比，以及适用与不适用的代码场景。

本节配有交互动效（进入视口后自动加载，约 3KB）。

JIT编译流程 Python代码经@jit装饰器触发即时编译 通过LLVM生成机器码，跳过解释器开销 Py → @jit → LLVM IR → Machine Code 一行装饰器即可将数值计算加速百倍

初识 Numba：一张认证卡，大厨变快厨

想象一家老牌餐厅的后厨。有位老厨师手艺不错，但有个“死板”的习惯：无论同一道菜做过多少遍，他都会重新翻开菜谱，一行一行照着做。这就像 Python 解释器——每次运行同一段代码，都要重新逐行解释，从不利用“上次已经做过”的记忆。客人等得心急，老板也头疼。

有一天老板招来一位新主厨，名叫 Numba。他接过菜谱，只在封面贴了一张名片大小的小卡片——上面印着三个字符 "@jit"。从那天起，凡是贴了这张卡的菜，新主厨第一次做时依然不紧不慢，但从第二次开始，出菜速度简直像变了个人。老厨师翻三页菜谱的功夫，他已经把整桌菜端上来了。

这张“认证卡”的本质，是 Python 生态中最著名的 JIT（Just-In-Time，即时编译）加速库——Numba。用法简单到不像话：在函数定义前加一行 @jit（最常用的是更严格的 @njit），Numba 就会在第一次被调用时，把 Python 字节码整体编译成 CPU 直接执行的机器码。对纯数值计算函数来说，几十倍到几百倍的加速是常态。原因在于：Python 是动态解释执行，每次循环都要做类型检查、对象分发；而编译后的机器码把这些开销全部抹平，循环体只剩几条简单的算术指令。

对老板来说，最动人的不是新主厨的厨艺，而是那句“一个标签即可启用”——不用换菜谱、不用添厨具、不用把厨房翻新一遍。一行 @jit，就是那张让老厨房焕然一新的认证卡。

S=TpythonTnumba\displaystyle S = \frac{T_{\text{python}}}{T_{\text{numba}}}
这个公式衡量 Numba 带来的“加速倍数”：老厨师做一道菜要 100 秒，新主厨只要 1 秒，S 就等于 100，说明快了 100 倍。
  1. T_python——基准耗时这是老厨师按老菜谱慢做一道菜的时间，也就是加速前的对照值。
    TpythonT_{\text{python}}
  2. T_numba——加速后耗时这是新主厨贴上认证卡之后，做同一道菜所需的时间。
    TnumbaT_{\text{numba}}
  3. S——加速比两者相除，得到“快了多少倍”；S 越大，收益越明显。
    S=TpythonTnumbaS = \frac{T_{\text{python}}}{T_{\text{numba}}}

编译原理：主厨的背菜谱功夫

新主厨为什么第二次出菜那么快？因为他第一次拿到新菜谱时，并没有急着开火，而是关起门来“研究食材”。他把牛肉、土豆、调料一一摆开，确认每样食材的“脾气”——牛肉就是牛肉、土豆就是土豆，绝不允许中途换成冬瓜。这就是 JIT 的“类型推断”：在编译之前，先把函数里每个变量的类型固定下来。

在 Numba 的世界里，这个过程发生在函数的第一次调用。它先分析函数参数和局部变量的类型（比如参数是 float64 数组，循环变量 i 是 int64），然后生成一份“中间菜谱”——LLVM 中间表达（IR），最后交给 LLVM 后端编译成针对当前 CPU 的机器码。这份机器码会被缓存下来，下一次调用直接加载，连“翻菜谱”都省了。

这个“研究食材”的时间在 Numba 里叫编译预热（warmup）。一次典型预热可能需要几十毫秒甚至更久，因此首次调用常常比纯 Python 还慢。但只要函数被反复调用，编译成本就会被摊薄。这就是“以一次慢，换万次快”的生意——调用次数越多，这笔买卖越划算。

主厨的“背菜谱”看似耽误了第一单生意，但因为他把食材和步骤记成了肌肉记忆，后续每一单都是闭眼颠勺。Numba 的缓存，就是主厨那本烂熟于心的菜谱——差别在于，这本菜谱是用机器码写的。

Ttotal=Twarmup+N×texec\displaystyle T_{\text{total}} = T_{\text{warmup}} + N \times t_{\text{exec}}
总耗时等于一次性预热开销，加上调用次数乘以单次执行时间。当 N 从几百涨到几百万，预热成本就被摊到几乎看不见。
  1. T_warmup——编译预热开销第一次调用时，类型推断和机器码生成所花的时间，这笔钱只付一次。
    TwarmupT_{\text{warmup}}
  2. N——调用次数函数被调用的总回数。N 越大，预热的“固定成本”越值得。
    NN
  3. t_exec——单次执行耗时编译完成后每次调用的耗时，数值极小，是新主厨“闭眼颠勺”的速度。
    texect_{\text{exec}}
  4. T_total——总账全部耗时 = 一次性预热 + 所有调用的执行耗时之和。
    Ttotal=Twarmup+N×texecT_{\text{total}} = T_{\text{warmup}} + N \times t_{\text{exec}}

nopython 模式：是全程闭眼，还是中途翻书

主厨有两种做菜状态。第一种，全程凭肌肉记忆，从食材下锅到出锅一气呵成；第二种，做到一半遇到不熟的步骤，还得屁颠屁颠跑回老厨师那儿翻菜谱——一翻书，节奏就全乱了。

对应到 Numba，就是 nopython 模式与 object 模式。默认的 @jit 其实带了一个“保险丝”：如果 Numba 发现函数里有些操作它编译不了——比如调用 Python 对象的方法——它就自动降级，切换到 object 模式。在这种模式下，数值部分虽然也尝试编译，但只要碰到 Python 对象，就得回到 Python 解释器，相当于“边做菜边翻书”。

降级带来的后果是性能大打折扣：object 模式的加速比通常只有 1~3 倍，有时甚至更慢。而 @jit(nopython=True)（等价于 @njit）则直接拔掉保险丝，强制 Numba“全程闭眼”——不允许任何 Python 对象混进来，只要函数里有一点不受支持的特性，就直接编译失败、大声报错。这种“粗暴”反而让人安心：要么编译成功、快到飞起；要么当场暴露问题。nopython 模式下，数值循环的加速比可以逼近 100 倍甚至更高。

老板总结出一条经验：想吃到主厨的真正手艺，必须让他全程闭眼颠勺，中途翻书的“半吊子模式”（object）只是听起来安全，实际上既没速度也没省心。于是他把后厨的规矩改成：拿手菜一律 @njit。

Snopython≈100  ≫  Sobject≈1∼3\displaystyle S_{\text{nopython}} \approx 100 \;\gg\; S_{\text{object}} \approx 1 \sim 3
nopython 模式像练到极致的肌肉记忆，能快约 100 倍；object 模式边做边翻书，只有 1~3 倍。两个模式之间的差距，不是“略慢一点”，而是“差了整整两个数量级”。
  1. S_nopython——全程编译的加速比完全靠肌肉记忆做菜的速度，数值逼近 100 倍。
    Snopython≈100S_{\text{nopython}} \approx 100
  2. S_object——回退模式的加速比中途翻菜谱做菜的速度，只有 1~3 倍。
    Sobject≈1∼3S_{\text{object}} \approx 1 \sim 3
  3. ≫——远大于符号表示两者差距悬殊，也是选择模式的决策依据。
    Snopython≫SobjectS_{\text{nopython}} \gg S_{\text{object}}

对比 Cython：预制菜工厂 vs 现场记忆派

隔壁餐厅走的完全是另一条路线：他们把每道菜提前做成“预制菜”——标准化配方、半成品包装，客人一下单就加热上桌。这套流程叫 AOT（Ahead-of-Time，提前编译）。而我们店的新主厨是“现场记忆派”：客人点菜才开背菜谱，从来不提前准备。

Cython 就是 Python 世界里的“中央厨房”。它要求开发者手动为函数的参数和局部变量标注类型，写上 cdef、cpdef 等声明，甚至可以直接嵌入 C 代码，然后一次性编译成 Python 扩展模块。这套方案成熟、可控、性能上限高，但代价是代码不再像 Python——维护起来像在经营一个“混血后厨”。

Numba 则把“何时编译”的决定权交给了运行时：不需要开发者标注类型，第一次调用时自己看参数类型、现场编译。代价是首次调用需要承担 warmup；而 Cython 的编译发生在部署环节，程序启动时已经是“完全体”。从代码侵入度来看，同样一个数值函数，Cython 通常要新增 3~5 行类型声明，Numba 只需在函数头顶加一行装饰器。

预制菜工厂稳定、可预期，但准备工序繁琐；现场记忆派随叫随到、改动极小，但头一次会慢。没有绝对的优劣——如果你追求“改一行代码就提速”，Numba 是更轻的选择；如果你要发行一个高性能扩展库，Cython 依然可靠。

R=LNumbaLCython≈13∼15\displaystyle R = \frac{L_{\text{Numba}}}{L_{\text{Cython}}} \approx \frac{1}{3} \sim \frac{1}{5}
这个比值表示两种方案的代码改动量差距：Numba 平均只需动 1 行，Cython 要动 3~5 行。改得越少，原项目被破坏的风险就越低。
  1. L_Numba——Numba 的改动行数给函数加一行 @njit，可能再调整个别不规范写法，累计改动量很小。
    LNumbaL_{\text{Numba}}
  2. L_Cython——Cython 的改动行数类型声明、cdef 变量、编译配置，每一项都要加到代码里。
    LCythonL_{\text{Cython}}
  3. R——改动比两者相除得到约 1/3 到 1/5，量化了“零侵入”的优势。
    R=LNumbaLCythonR = \frac{L_{\text{Numba}}}{L_{\text{Cython}}}

适用场景：哪些菜配得上拿手绝活

主厨的绝活不是万能的。他最擅长的是那种“食材固定、火候固定、大批量翻炒”的硬菜；你非要他做分子料理、创意甜品，他只会干瞪眼。老板很快发现，只有把时间花在硬菜上的客人，才会真心夸主厨厉害。

Numba 擅长的代码和“硬菜”高度相似：数值密集、循环沉重、类型明确。典型场景有三大类：纯数值循环（比如逐元素累加、矩阵运算）、NumPy 数组的基础操作（大部分 ufunc 和切片运算）、机器学习算法里反复执行的距离计算、梯度更新、蒙特卡洛模拟等。性能优化领域称这些函数为“热点”（hotspot），它们正是 JIT 的主战场。

但加速收益不是“贴了卡就起飞”，它受 Amdahl 定律约束。如果数值计算只占整个程序的 10%，这部分就算快 100 倍，整体最多也只提速 1.23 倍。所以正确的姿势永远是：先用性能分析工具（如 cProfile、py-spy）找到热点，再只对热点函数加 @njit。

老板在后厨立了规矩：只有真正占用大量烹饪时间的“当家硬菜”才允许动用主厨的绝活；那些跑龙套的前菜、小炒，交给老厨师顺手做掉就行。优化，永远是“测过再动刀”。

Smax=1(1−p)+ps\displaystyle S_{\text{max}} = \frac{1}{(1 - p) + \dfrac{p}{s}}
Amdahl 定律说的是“木桶效应”：你能提速的上限，被那些无法加速的部分死死卡住。p 是能加速部分的占比，p 越大、s 越高，整体收益才越可观。
  1. p——可加速部分占比数值计算在总耗时中的比例，比如 80% 的时间都花在循环里。
    pp
  2. s——局部加速倍数Numba 让数值部分快了多少倍，比如 100 倍。
    ss
  3. 1-p——不可加速部分无法用 Numba 加速的 I/O、字符串、对象操作等，是拖后腿的短板。
    1−p1 - p
  4. S_max——整体最大加速比带入公式算出的总提升上界，提醒我们先把力气花在 p 最大的地方。
    Smax=1(1−p)+psS_{\text{max}} = \frac{1}{(1 - p) + \dfrac{p}{s}}

使用限制：有些菜，主厨真的做不了

有一天，客人点了一道“活体分子料理”——食材是活的、随时会变，还要求现场搭配，甚至要用到隔壁店的专用厨具。新主厨斟酌了半天，摇摇头：“这道菜没有固定配方，我记不住肌肉记忆，还是请老厨师吧。”

Numba 的 nopython 模式支持的 Python 特性是“木讷”且有边界的。它喜欢数值标量、NumPy 数组，支持 if/for/while 控制流和一堆数学函数。但遇到 Python 对象——比如包含多种类型的 list、dict、自定义类实例——它就无能为力了。第三方库更是重灾区：pandas 的 DataFrame、字符串处理的正则模块、大部分 IO 操作，都无法进入 nopython 世界。

最阴险的坑是“静默回退”：@jit 在编译失败时默认不报错，悄悄退回 object 模式，程序照样运行，输出照样正确，但加速几乎归零。如果你不知道这个机制，会以为 Numba“没有效果”。对策很简单：使用 @njit（强制 nopython），让编译期失败直接暴露；或者在测试阶段检查函数是否真的走了 nopython 编译路径。

老板在菜单扉页印了一行小字：“主厨拿手菜范围有限”。超出范围的菜，请直接交给老厨师；千万别让主厨“半记忆半翻书”硬做——那样既没了速度，又丢了招牌。

Mode(f)={nopythonif f∈Supportedobjectif f∈Unsupported\displaystyle \text{Mode}(f) = \begin{cases} \text{nopython} & \text{if } f \in \text{Supported} \\ \text{object} & \text{if } f \in \text{Unsupported} \end{cases}
这个分段公式概括了 Numba 的“接单规则”：函数只含受支持语法时，走 nopython 快速通道；一旦碰到不支持的动态特性，就自动滑入 object 慢速通道。
  1. Mode(f)——实际编译模式Numba 对函数 f 最终采取的执行方式，只有 nopython 或 object 两种。
    Mode(f)\text{Mode}(f)
  2. Supported——受支持集合数值运算、控制流、NumPy 基础函数等“木讷”代码，属于主厨能背下来的配方。
    Supported(f)=true\text{Supported}(f) = \text{true}
  3. Unsupported——不受支持集合动态对象、第三方库、正则等“活食材”，只能回退到老厨师模式。
    otherwise⇒object\text{otherwise} \Rightarrow \text{object}

实战参数：点单技巧，让大厨火力全开

相处久了，老板摸清了让主厨火力全开的三个技巧：给他一张“永久菜单卡”，不用每天重新背菜谱；跟他说“这桌不必等上一桌的客人”，他可以同时开几个灶；再给他“多手联炒”的权限，一道菜还能拆成几锅同时做。

这几个技巧对应 Numba 的实用参数。cache=True 把编译好的机器码写入磁盘缓存，下次进程启动直接加载，省掉重复的 warmup；nogil=True 让 Numba 函数运行期间释放 Python 的 GIL，配合多线程可以真正并行执行；parallel=True 配合 prange 循环，让 Numba 自动把循环体拆分到多核并行计算。另外还有“提前报菜名”——通过函数签名（如 @jit("float64(float64[:])")）预先指定参数类型，省去运行时类型推断。

实际项目里最常用的组合是 @njit(cache=True, nogil=True)。并行化要小心：parallel=True 只对特定模式的循环生效，而且线程调度、内存拷贝会带来额外开销，数据量太小时反而更慢。理论上 n 核并行加速比最多接近 n，但考虑到内存带宽和调度开销，真实值通常只有 n 的 80%~95%。

一行装饰器只是入场券，真正的加速藏在参数组合里。老板把那三条点单技巧裱起来挂在后厨墙上，从此主厨的拿手菜，再也没有让客人等超过十秒。

E=Snn≈0.8∼0.95\displaystyle E = \frac{S_n}{n} \approx 0.8 \sim 0.95
并行效率 E 描述“多核到底值不值”：理想情况开 4 个核就快 4 倍，E 等于 1；现实因为开销只有 0.8~0.95，已经算非常高效。
  1. n——CPU 核心数老板给主厨开的小灶数量，比如 4 核或 8 核。
    nn
  2. S_n——n 核实际加速比开了 n 个灶之后，整体出菜时间缩短的倍数。
    SnS_n
  3. E——并行效率实际加速比除以核数，越接近 1 说明多核扩展性越好，0.8~0.95 是健康区间。
    E=SnnE = \frac{S_n}{n}

AI 应用场景

KNN 距离矩阵计算

阶段：特征工程 / 模型训练前的数据预处理

解决的问题：K 近邻算法需要对 N 个样本两两计算欧氏距离，双层 for 循环在纯 Python 下是 O(N²) 的灾难；NumPy 向量化虽然能加速，但会生成巨大的中间矩阵，内存吃紧。Numba 让代码保持直观的双层循环写法，同时获得接近 C 的速度，是“少写代码、少耗内存、快出结果”三全其美。

具体案例：一个推荐系统项目需要对 5 万用户 x 300 维特征做相似度矩阵，纯 Python 需要 40 分钟，NumPy 向量化方案 5 分钟但内存峰值很高，改用 @njit 距离函数后只需 20 秒，峰值内存还更低。

蒙特卡洛期权定价

阶段：风险模拟 / 衍生品定价

解决的问题：期权定价要模拟上百万条随机价格路径，每条路径都要走几十步随机游走；纯 Python 的随机数循环慢到无法做参数敏感性分析。Numba 在 nopython 模式下原生支持 np.random 系列函数，可以在编译后的代码里直接生成随机数并完成路径计算。

具体案例：欧式看涨期权定价，模拟 1 亿条路径，纯 Python 约需 7 分钟；使用 @njit 加 parallel=True 后 10 秒内完成，还能配合 nogil 让多线程同时跑多组参数。

图像卷积滤波

阶段：图像预处理 / 特征提取

解决的问题：3×3 卷积需要对每个像素遍历邻域，三层 for 循环在 Python 中是性能灾难，而用 Numba 可以把卷积核逻辑写成易读的循环，同时保持 C 级别的执行速度，特别适合算法工程师快速迭代原型。

具体案例：在 4K 图像上做 5×5 高斯模糊，纯 Python 要几分钟；@njit 版本只需要几百毫秒。CV 算法团队在调参时不用再对着进度条干等。

Python 演示

python39 行
import timeimport numpy as npfrom numba import jit  @jit(nopython=True)def sum_squares(arr):    total = 0.0    for i in range(arr.size):        total += arr[i] * arr[i]    return total  def sum_squares_py(arr):    total = 0.0    for i in range(arr.size):        total += arr[i] * arr[i]    return total  def main():    n = 10_000_000    arr = np.random.random(n)     sum_squares(arr)  # 编译预热: 触发 JIT     t0 = time.perf_counter()    _ = sum_squares_py(arr)    t1 = time.perf_counter()    _ = sum_squares(arr)    t2 = time.perf_counter()     print(f"Python time: {t1 - t0:.3f}s")    print(f"Numba time: {t2 - t1:.3f}s")    print(f"Speedup: {(t1 - t0) / (t2 - t1):.1f}x")  if __name__ == "__main__":    main()
目的：演示同一个“数组平方和”函数，在纯 Python 与 Numba JIT 下的耗时差异，输出加速倍数。
  1. @jit(nopython=True)这就是那张“米其林认证卡”，强制全程编译，不碰 Python 对象。
  2. total = 0.0注意初始值是浮点数，Numba 会据此把 total 推断为 float64。
  3. for i in range(arr.size)这段循环是 Numba 最擅长的“数值硬菜”，会被编译成机器码。
  4. arr[i] * arr[i]编译后这里不再有 Python 对象开销，只剩 CPU 算数指令。
  5. (t1 - t0) / (t2 - t1)两段耗时相除，算出这行装饰器带来的加速倍数。

常见误区

误区听说 Numba 很神，我给所有函数都加上 @jit，结果有的函数反而更慢了，是不是装错了库？

正解@jit 只对数值密集型函数有效。如果函数里大多是字典操作、字符串处理，或调用第三方库，Numba 编译不了就会退回 object 模式，几乎没有加速甚至更慢。就像让“硬菜主厨”去做分子料理，他只能边做边翻书，当然快不起来。正确做法是先用性能分析工具找到热点，只给热点函数加 @jit。

为何常见：Numba 的宣传让大家误以为“一行装饰器”是万能加速器，忽略了 JIT 有明确的适用边界。

误区第一次调用比纯 Python 还慢，感觉被忽悠了，是不是应该卸库？

正解第一次慢是编译预热（warmup）的正常现象。Numba 首次调用要做类型推断并生成机器码，相当于主厨第一次研究食材形成肌肉记忆。真正要关注的是“总账”——当调用次数上去了，warmup 会被摊薄到可以忽略。生产环境配合 cache=True，还能把预热从每次进程启动中省掉。

为何常见：人们习惯用单次运行的体验做评价，却没有从“多次调用的总耗时”角度算账。

误区@jit 会自动回退，程序不会崩，用 @jit 更稳妥，@njit 太容易报错了。

正解@jit 的“安全”是以性能为代价的。一旦进入 object 模式，可能只有 1~2 倍提升甚至更慢，而你浑然不觉。用 @njit（等价于 nopython=True）能立刻暴露编译失败，避免“看似加速实则没加速”的假象。真正稳妥的做法是：在开发期用 @njit 把问题逼出来，确认能编译后再决定是否放宽。

为何常见：回退是静默的，开发者往往不知道自己的函数到底走没走 nopython 路径。

误区我用了 np.dot、np.linalg 这种成熟库，Numba 一定能再快一步吧？

正解NumPy 内部本来就是 C 实现的，很多向量化操作本身已很快。Numba 的优势在于“把 Python 级的多层循环压成机器码”，而不是取代已经 C 化的 NumPy 内核。某些 NumPy 函数在 Numba 里的实现反而不如原生 NumPy 快，尤其是数据规模较小时，编译和调度开销可能盖过收益。

为何常见：把“Python 慢”等同于“NumPy 慢”，其实 NumPy 的瓶颈通常在 Python 层封装和内存开销，而不是内核计算。

面试题

Q1. Numba 中的 "JIT" 全称是什么？

单选题 · easy

  • A.交互工具集
  • B.即时编译技术← 正确答案
  • C.联合推理框架
  • D.数据导入模块

答案：B。JIT 是 Just-In-Time 的缩写，表示“即时编译”——在运行时才把代码编译成机器码，而不是像 C 语言那样在运行前就编译好。好比新主厨是客人点菜后才开始背配方，而不是提前做好预制菜。

Q2. @njit 装饰器等价于下面哪种写法？

单选题 · easy

  • A.@jit(nopython=True)← 正确答案
  • B.@jit(forceobj=True)
  • C.@jit(cache=True)
  • D.@jit(parallel=True)

答案：A。@njit 是 @jit(nopython=True) 的简写，强制 Numba 全程编译、不碰 Python 对象。B 的 forceobj 不是合法参数，C 只开缓存，D 只开并行，都不等价。

Q3. 下列哪些代码特征适合用 Numba 加速？

多选题 · mid

  • A.字典键值频繁增删
  • B.数值密集的多层循环← 正确答案
  • C.大量字符串正则处理
  • D.NumPy 数组逐元素运算← 正确答案

答案：BD。Numba 擅长“数值硬菜”——多层数值循环和 NumPy 数组运算是它的主场，能编成机器码；字典增删和字符串正则是动态特性，nopython 模式不支持，强行编译会回退 object 模式，加速几乎消失。

Q4. Numba 函数第一次调用比纯 Python 慢，最直接原因是什么？

单选题 · mid

  • A.计算机内存突然不足了
  • B.Python 解释器临时降速
  • C.首次调用需要编译机器码← 正确答案
  • D.函数内部逻辑发生了变化

答案：C。第一次调用要完成类型推断、LLVM 中间码生成和机器码编译——相当于主厨第一次研究食材形成肌肉记忆的“预热”阶段。这笔开销只付一次，之后每次调用都会复用编译产物。

Q5. 函数内部使用 DataFrame，在 nopython 模式下会发生什么？

单选题 · mid

  • A.编译失败并回退 object 模式← 正确答案
  • B.Numba 自动重新实现 DataFrame
  • C.运行时直接崩溃程序终止
  • D.编译成功但结果不可靠

答案：A。pandas 的 DataFrame 是 Python 对象，nopython 模式不支持，所以编译失败。但 @jit 默认会静默回退到 object 模式，程序照跑，代价是几乎没加速——这正是推荐用 @njit 强制暴露问题的原因。

Q6. 下列哪些代码会让 nopython 编译失败？

多选题 · hard

  • A.使用自定义类的实例方法← 正确答案
  • B.对整数数组做算术运算
  • C.调用正则表达式 re 模块← 正确答案
  • D.使用 Python 字典传参← 正确答案

答案：ACD。nopython 模式只认“木讷”的数值数据和 NumPy 数组。自定义类、正则模块、Python 字典都是“活的”动态对象，无法编成机器码；整数数组的算术运算是完全受支持的。

Q7. Numba 与 Cython 加速方案的核心理念区别是什么？

单选题 · mid

  • A.两者都必须在 C 语言修改
  • B.编译时机和改动量不同← 正确答案
  • C.Numba 不适合数值计算
  • D.Cython 不需要做类型标注

答案：B。Cython 走“中央厨房”路线——AOT 提前编译，要求手动标注类型；Numba 走“现场即兴”路线——JIT 运行时编译，一行装饰器搞定。两者代码改动量差异约 3~5 倍。

Q8. 给 @jit 添加 cache=True，最主要的作用是什么？

单选题 · easy

  • A.让代码自动并行多核执行
  • B.释放 GIL 支持多线程
  • C.强制函数走 object 模式
  • D.编译产物落盘复用跨进程← 正确答案

答案：D。cache=True 会把编译好的机器码写入磁盘缓存。下一次启动进程时，Numba 发现缓存存在就直接加载，跳过“主厨重新背菜谱”的预热环节。并行靠 parallel，多线程靠 nogil，都与 cache 无关。

Q9. 根据 Amdahl 定律，关于 Numba 优化策略哪些说法正确？

多选题 · hard

  • A.整体提升受不可加速部分限制← 正确答案
  • B.应优先加速耗时占比大的热点← 正确答案
  • C.加速所有代码收益线性增长
  • D.优化前应分析性能瓶颈分布← 正确答案

答案：ABD。Amdahl 定律说整体加速比 = 1 / [(1-p) + p/s]，其中 p 是可加速部分占比。如果 p 只有 20%，就算 s 趋近无穷，整体最多提速 1.25 倍。所以必须先分析瓶颈、聚焦热点，而不是无差别给所有函数加 @jit。

Q10. 某函数加了 @jit 后运行成功且结果正确，但实际走的是 object 模式，最可能出现什么情况？

单选题 · extreme

  • A.程序一定会报错失控
  • B.速度比 nopython 还快百倍
  • C.加速效果接近纯 Python← 正确答案
  • D.Numba 会打印大段警告

答案：C。object 模式意味着 Numba 编译失败后回退到 Python 解释器执行，除了少量调度开销外，速度与纯 Python 几乎没有差别。它不会打印大段警告，也不一定会报错——这正是“静默回退”最坑的地方。