JS函数执行时间怎么测？

本文深入探讨了如何精确测量JavaScript函数的执行时间，为开发者提供了一份全面的性能分析指南。文章详细介绍了`console.time()`、`performance.now()`、`process.hrtime.bigint()`以及`Date.now()`等多种测量方法，并分析了它们各自的适用场景和精度差异。同时，文章还强调了精确测量的重要性，指出其在定位性能瓶颈、指导优化方向、验证优化效果以及提升用户体验方面的关键作用。此外，文章还介绍了浏览器Performance面板、Lighthouse、Node.js Profiler和Web Vitals等实用工具，并深入剖析了JIT编译、垃圾回收、环境差异和异步操作等因素对测量结果的影响，并提供了相应的优化建议，旨在帮助开发者更准确地评估JavaScript代码的性能。

答案是使用console.time()、performance.now()、process.hrtime.bigint()和Date.now()等方法测量JavaScript函数执行时间。console.time()适合快速调试；performance.now()提供高精度跨平台计时；process.hrtime.bigint()在Node.js中实现纳秒级精度；Date.now()兼容性好但精度低。精确测量有助于定位性能瓶颈、指导优化、验证效果并提升用户体验。结合浏览器Performance面板、Lighthouse、Node.js Profiler和Web Vitals等工具可全面分析性能。测量结果受JIT编译、垃圾回收、环境差异和异步操作等因素影响，需通过预热、重复执行、隔离环境和使用专业库（如benchmark.js）来优化测量准确性。

要测量JavaScript函数的执行时间，最直接也最常用的方法是利用浏览器或Node.js提供的计时API，比如console.time()/console.timeEnd()或者更精确的performance.now()。它们能帮助我们快速定位性能瓶颈，理解代码运行的实际开销。

解决方案

在实际开发中，我通常会根据场景选择不同的测量方式。

1. console.time() 和 console.timeEnd()：快速粗略的评估

这是我日常调试中最常用的方式，因为它简单直接，不需要引入额外变量。当你需要快速查看某个代码块或函数大概运行了多久时，它简直是神器。

console.time('myFunctionExecution'); // 启动计时器，标签为'myFunctionExecution'

function myFunction() {
  let sum = 0;
  for (let i = 0; i < 1000000; i++) {
    sum += i;
  }
  return sum;
}

myFunction();

console.timeEnd('myFunctionExecution'); // 停止计时器，并输出'myFunctionExecution: XX.XXXms'

它会在控制台输出从time()调用到timeEnd()调用之间的时间差。但要注意，这个方法主要用于开发环境的调试，不适合做生产环境的精确性能监控，因为它依赖于控制台输出，且精度可能不如performance.now()。而且，它的计时是基于系统时间，如果系统时间被调整，可能会有偏差。

2. performance.now()：高精度、浏览器和Node.js通用

当我需要更精确的计时，或者需要在代码逻辑中获取时间差进行进一步处理时，performance.now()是我的首选。它返回一个高精度的时间戳，以毫秒为单位，从页面加载（或Node.js进程启动）开始计算，并且不受系统时钟调整的影响。

const startTime = performance.now(); // 获取开始时间戳

function anotherFunction() {
  let result = 1;
  for (let i = 0; i < 5000000; i++) {
    result *= (i % 2 === 0 ? 1.000001 : 0.999999); // 模拟一些浮点运算
  }
  return result;
}

anotherFunction();

const endTime = performance.now(); // 获取结束时间戳
const executionTime = endTime - startTime; // 计算执行时间
console.log(`anotherFunction took ${executionTime.toFixed(3)} milliseconds.`);

performance.now()的精度通常可以达到微秒级别，这对于测量短时间内的函数执行非常有帮助。在Node.js环境中，performance.now()同样可用，它会返回自Node.js进程启动以来的毫秒数。

3. Node.js特有：process.hrtime.bigint() (或 process.hrtime())：纳秒级精度

在Node.js后端服务中，有时我们需要更极致的精度，比如纳秒级，这时process.hrtime.bigint()就派上用场了。它返回一个BigInt类型的时间差，避免了浮点数精度问题。

if (typeof process !== 'undefined' && process.hrtime) { // 确保在Node.js环境
  const startHrTime = process.hrtime.bigint(); // 获取高精度开始时间（纳秒）

  function nodeSpecificTask() {
    let data = [];
    for (let i = 0; i < 100000; i++) {
      data.push(Math.random());
    }
    data.sort((a, b) => a - b);
    return data;
  }

  nodeSpecificTask();

  const endHrTime = process.hrtime.bigint(); // 获取高精度结束时间
  const executionTimeNs = endHrTime - startHrTime; // 纳秒级时间差
  console.log(`nodeSpecificTask took ${executionTimeNs} nanoseconds.`);
  console.log(`nodeSpecificTask took ${Number(executionTimeNs) / 1_000_000} milliseconds.`);
} else {
  console.warn('process.hrtime.bigint() is only available in Node.js environment.');
}

process.hrtime()是其老版本，返回一个[seconds, nanoseconds]数组，需要手动计算。bigint()版本更方便。

4. Date.now()：低精度、兼容性最好

虽然精度最低，但Date.now()在所有JavaScript环境中都可用，包括一些非常老的浏览器。它返回自Unix纪元（1970年1月1日00:00:00 UTC）以来的毫秒数。如果你只是需要一个大致的、毫秒级别的粗略计时，并且非常看重兼容性，它也能勉强用。

const start = Date.now();

function legacyFunction() {
  let temp = 0;
  for (let i = 0; i < 50000; i++) {
    temp += Math.sqrt(i);
  }
  return temp;
}

legacyFunction();

const end = Date.now();
console.log(`legacyFunction took ${end - start} milliseconds.`);

不过，我个人很少用它来做性能测量，因为它的精度不足以应对现代JavaScript应用的性能分析需求，而且它也受系统时钟调整的影响。

为什么精确测量JS函数性能至关重要？

精确测量JavaScript函数性能，在我看来，不仅仅是为了满足好奇心，更是构建高性能、用户友好应用的基石。我曾遇到过一个看似简单的循环操作，在数据量增大后，导致整个页面卡顿数秒，用户体验极差。如果没有精确的测量，我们可能只会凭感觉优化，效率低下，甚至南辕北辙。

首先，它能揭示真正的性能瓶颈。很多时候，我们凭直觉认为某个部分慢，但实际测量结果可能指向完全不同的代码块。比如，我曾以为是DOM操作慢，结果发现是数据处理逻辑耗时更长。精确的测量能帮助我们把精力投入到最有价值的优化点上。

其次，它指导优化方向。知道哪个函数慢，我们才能有针对性地去重构算法、优化数据结构，或者考虑异步处理。比如，一个函数执行时间过长，可能意味着它做了太多同步操作，或者算法复杂度过高。有了数据，我们就能决定是引入Web Workers、使用更高效的Map/Set，还是调整循环逻辑。

再者，它验证优化效果。优化前后的性能对比是衡量优化是否成功的唯一标准。我通常会记录下优化前后的执行时间，如果优化后时间显著缩短，那说明我的努力没有白费。这也能为团队的技术决策提供数据支撑。

最后，它提升用户体验。无论是前端的页面响应速度、动画流畅度，还是后端的API处理延迟，都直接影响用户感受。一个秒开的页面和一个卡顿的页面，用户体验天壤之别。精确测量并优化，就是为了让用户能顺畅、愉快地使用我们的产品。这不仅仅是技术问题，更是产品竞争力的问题。

除了计时，还有哪些JS性能分析工具？

当然，仅仅依靠console.time()或performance.now()来测量单个函数执行时间是远远不够的。在实际的性能优化工作中，我更倾向于使用更强大的工具，它们能提供更全面的视角，帮助我理解整个应用的性能状况。

1. 浏览器开发者工具（Performance Tab）

这是我最常使用的“瑞士军刀”。以Chrome为例，它的Performance面板简直是前端性能分析的宝藏。我通常会：

• 录制性能会话：点击录制按钮，模拟用户操作，然后停止。
• 分析火焰图（Flame Chart）：这里能清晰地看到CPU在哪些函数上花费了时间，哪个函数调用了哪个函数，以及它们的耗时占比。我可以一眼看出哪些函数是“热点”，哪些是“冷点”。我特别喜欢看那些宽大的“火焰”，它们往往是性能瓶凶手。
• 查看网络、渲染、脚本活动：除了JS执行，Performance面板还会显示网络请求、DOM操作、样式计算、布局和绘制等所有活动，帮助我理解JS执行是如何影响渲染管线的。比如，一个长时间运行的JS任务可能会阻塞渲染，导致页面卡顿。
• 垃圾回收（GC）事件：GC也是一个常见的性能陷阱。在Performance面板中，可以看到GC事件的发生时间和持续时间，如果GC过于频繁或耗时过长，可能需要优化内存使用。

2. Lighthouse

Lighthouse是一个自动化工具，可以对网页进行多方面的审计，包括性能、可访问性、最佳实践、SEO等。我通常会在发布前或进行大型优化时运行Lighthouse，它会给我一个综合评分，并提供具体的改进建议，比如“减少主线程工作”、“避免巨大的网络负载”等。虽然它不直接测量单个函数，但它从用户体验的角度评估整体性能，指引我从宏观层面进行优化。

3. Node.js Profiler (例如 node --inspect 或 0x)

在Node.js后端，我通常会使用内置的V8 Inspector协议配合Chrome DevTools或者专门的工具如0x。

• node --inspect：启动Node.js应用时加上这个参数，然后在Chrome浏览器中打开chrome://inspect，就可以连接到Node.js进程，使用熟悉的DevTools进行CPU Profiling。这与浏览器端的Performance面板体验类似，可以生成火焰图，分析后端JS的CPU使用情况。
• 0x：这是一个更专业的Node.js性能分析工具，它能生成漂亮的火焰图，并且易于使用。它能帮助我快速定位Node.js应用中的CPU密集型任务，找出哪些函数在后端占用了大量计算资源。

4. Web Vitals API (LCP, FID, CLS)

这些是Google推出的一组核心Web指标，用于衡量用户体验。虽然它们不是直接的函数计时工具，但它们是评估前端性能的最终标准。例如：

• Largest Contentful Paint (LCP)：衡量最大内容元素渲染时间，JS执行如果阻塞了渲染，会影响LCP。
• First Input Delay (FID)：衡量用户首次交互（如点击）到浏览器响应之间的时间，长时间的JS任务会直接导致高FID。
• Cumulative Layout Shift (CLS)：衡量页面布局的意外偏移，不稳定的JS操作可能导致布局抖动。

通过监控这些指标，我可以从用户角度反推JS代码的性能表现。

测量结果受哪些因素影响，又该如何优化？

测量JavaScript函数执行时间，绝不是简单地跑一遍代码、记录时间那么简单。我踩过不少坑，也逐渐明白，测量结果受多方面因素影响，而且很多时候，我们看到的时间并不完全是函数本身的“纯”执行时间。

1. JIT编译（Just-In-Time Compilation）的影响

JavaScript引擎（如V8）会进行JIT编译，将热点代码（频繁执行的代码）编译成更快的机器码。这意味着：

• “冷启动”与“热启动”：函数第一次执行时，可能还没有被JIT优化，所以时间会比较长。后续执行时，如果已经被优化，时间会显著缩短。这就是为什么我通常会“预热”函数，让它跑几次，然后再开始正式测量。
• 优化与去优化：JIT优化是动态的，如果后续代码执行路径发生变化（比如传入了不同类型的数据），V8可能会“去优化”代码，导致性能下降。

优化策略：在进行基准测试时，确保函数有足够的“预热”时间。避免在循环内部改变变量类型或进行不稳定的操作，以帮助JIT保持代码的优化状态。

2. 垃圾回收（Garbage Collection, GC）

JavaScript是垃圾回收语言，GC会在后台自动运行，回收不再使用的内存。GC的发生是不可预测的，它可能会在你的函数执行过程中突然介入，暂停JS主线程，从而导致你的测量时间虚高。

优化策略：在测量关键代码块时，尽量避免创建大量临时对象，减少GC的压力。虽然我们无法完全控制GC，但在某些场景下，可以通过工具（如DevTools的Performance面板）观察GC事件，并尝试在测量前手动触发一次GC（虽然这不是标准做法，但在某些测试场景下有用）。

3. 浏览器/Node.js环境与硬件差异

• 浏览器扩展：某些浏览器扩展可能会注入JS，影响页面性能。
• 后台任务：操作系统或浏览器中的其他后台进程（如杀毒软件、其他标签页）可能会占用CPU资源。
• 硬件配置：CPU、内存等硬件差异对执行时间有显著影响。在我的低配笔记本上跑得慢的代码，在高性能台式机上可能飞快。

优化策略：在进行严肃的基准测试时，尽量在一个干净、隔离的环境中进行：关闭不必要的浏览器标签页和扩展，甚至重启浏览器或操作系统。如果可能，在相同或相似的硬件配置下进行测试。

4. 微基准测试的陷阱

测量非常小的、执行时间极短的代码片段（微基准测试）往往会非常困难且容易产生误导。因为JS引擎的内部优化、计时器的精度限制以及上述的JIT/GC影响，一个几微秒的函数，其测量误差可能比函数本身执行时间还长。

优化策略：

• 重复执行：将要测量的函数在一个大循环中重复执行成千上万次，然后测量整个循环的总时间，再除以循环次数。这样可以放大执行时间，减少单次测量的相对误差。
• 使用专门的库：例如benchmark.js这样的库，它能处理预热、多次运行、统计分析等复杂问题，提供更可靠的基准测试结果。
• 关注宏观性能：很多时候，微观的优化并不能带来实际的用户体验提升。我更倾向于关注那些宏观的、对用户感知影响更大的性能指标。

5. I/O操作与异步代码

如果函数内部包含网络请求、文件读写等I/O操作，或者使用了setTimeout、Promise等异步机制，那么简单的同步计时会非常不准确。performance.now()只能测量同步代码的执行时间。

优化策略：对于异步代码，你需要测量的是从异步操作发起，到其回调函数执行完毕的整个“生命周期”。这通常需要更复杂的逻辑，比如在Promise.then()或async/await的try...catch块中进行多次performance.now()测量，以跟踪不同阶段的耗时。

总之，测量JS函数执行时间是一门艺术，需要理解底层机制，并采取合适的工具和方法。没有银弹，只有不断尝试、分析和迭代。

到这里，我们也就讲完了《JS函数执行时间怎么测？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于性能优化,JIT编译,函数执行时间,performance.now(),JavaScript性能测量的知识点！