专栏首页前端皮小蛋「 不懂就问 」esbuild 为什么这么快?

「 不懂就问 」esbuild 为什么这么快?

前言

esbuild 是新一代的 JavaScript 打包工具。

他的作者是 Figma 的 CTO - Evan Wallace

( 这卡姿兰大眼睛,令人唏嘘的发际线, 一看就知道很强!)

esbuild速度快而著称,耗时只有 webpack 的 2% ~3%。

esbuild 项目主要目标是: 开辟一个构建工具性能的新时代,创建一个易用的现代打包器

它的主要功能:

  • Extreme speed without needing a cache
  • ES6 and CommonJS modules
  • Tree shaking of ES6 modules
  • An API for JavaScript and Go
  • TypeScript and JSX syntax
  • Source maps
  • Minification
  • Plugins

现在很多工具都内置了它,比如我们熟知的:

  • vite,
  • snowpack

借助 esbuild 优异的性能, vite 更是如虎添翼, 快到飞起。

今天我们就来探索一下: 为什么 esbuild 这么快?

下文的主要内容:

  • 几组性能数据对比
  • 为什么 esbuild 这么快
  • esbuild upcoming roadmap
  • esbuild 在 vite 中的运用
  • 为什么生产环境仍需打包?
  • 为何vite不用 esbuild 打包?
  • 总结

正文

先看一组对比:

使用 10 份 threeJS 的生产包,对比不同打包工具在默认配置下的打包速度。

webpack5 垫底, 耗时 55.25秒。

esbuild 仅耗时 0.37 秒。

差异巨大。

还有更多对比:

https://twitter.com/evanwallace/status/1314121407903617025

webpack5 表示很受伤: 我还比不过 webpack 4 ?

...

为什么 esbuild 这么快 ?

有以下几个原因。

(为了保证内容的准确性, 以下内容翻译自 esbuild 官网。)

1. 它是用 Go 语言编写的,并可以编译为本地代码。

大多数打包器都是用 JavaScript 编写的,但是对于 JIT 编译的语言来说,命令行应用程序拥有最差的性能表现。

每次运行打包器时,JavaScript VM 都会在没有任何优化提示的情况下看到打包程序的代码。

在 esbuild 忙于解析 JavaScript 时,node 忙于解析打包程序的JavaScript。

到节点完成解析打包程序代码的时间时,esbuild可能已经退出,您的打包程序甚至还没有开始打包。

另外,Go 是为并行性而设计的,而 JavaScript 不是。

Go在线程之间共享内存,而JavaScript必须在线程之间序列化数据。

Go 和 JavaScript都有并行的垃圾收集器,但是Go的堆在所有线程之间共享,而对于JavaScript, 每个JavaScript线程中都有一个单独的堆

根据测试,这似乎将 JavaScript worker 线程的并行能力减少了一半,大概是因为一半CPU核心正忙于为另一半收集垃圾。

2. 大量使用了并行操作。

esbuild 中的算法经过精心设计,可以充分利用CPU资源。

大致分为三个阶段:

  1. 解析
  2. 链接
  3. 代码生成

解析代码生成是大部分工作,并且可以完全并行化(链接在大多数情况下是固有的串行任务)。

由于所有线程共享内存,因此当捆绑导入同一JavaScript库的不同入口点时,可以轻松地共享工作。

大多数现代计算机具有多内核,因此并行性是一个巨大的胜利。

3. 代码都是自己写的, 没有使用第三方依赖。

自己编写所有内容, 而不是使用第三方库,可以带来很多性能优势。

可以从一开始就牢记性能,可以确保所有内容都使用一致的数据结构来避免昂贵的转换,并且可以在必要时进行广泛的体系结构更改。缺点当然是多了很多工作。

例如,许多捆绑程序都使用官方的TypeScript编译器作为解析器。

但是,它是为实现TypeScript编译器团队的目标而构建的,它们没有将性能作为头等大事。

4. 内存的高效利用。

理想情况下, 根据数据数据的长度, 编译器的复杂度为O(n).

如果要处理大量数据,内存访问速度可能会严重影响性能。

对数据进行的遍历次数越少(将数据转换成数据所需的不同表示形式也就越少),编译器就会越快。

例如,esbuild 仅触及整个JavaScript AST 3次:

  1. 进行词法分析,解析,作用域设置和声明符号的过程
  2. 绑定符号,最小化语法。比如:将 JSX / TS转换为 JS, ES Next 转换为 es5。
  3. 最小标识符,最小空格,生成代码。

当 AST 数据在CPU缓存中仍然处于活跃状态时,会最大化AST数据的重用。

其他打包器在单独的过程中执行这些步骤,而不是将它们交织在一起。

它们也可以在数据表示之间进行转换,将多个库组织在一起(例如:字符串→TS→JS→字符串,然后字符串→JS→旧的JS→字符串,然后字符串→JS→minified JS→字符串)。

这样会占用更多内存,并且会减慢速度。

Go的另一个好处是它可以将内容紧凑地存储在内存中,从而使它可以使用更少的内存并在CPU缓存中容纳更多内容。

所有对象字段的类型和字段都紧密地包装在一起,例如几个布尔标志每个仅占用一个字节。

Go 还具有值语义,可以将一个对象直接嵌入到另一个对象中,因此它是'免费的',无需另外分配。

JavaScript不具有这些功能,还具有其他缺点,例如 JIT 开销(例如隐藏的类插槽)和低效的表示形式(例如,非整数与指针堆分配)。

以上的每一条因素, 都能在一定程度上提高编译速度。

当它们共同工作时,效果比当今通常使用的其他打包器快几个数量级。

以上内容比较繁琐,对此,也有一些网友做了简要的总结:

  • 它是用 Go 语言编写的,该语言可以编译为本地代码。而且 Go 的执行速度很快。一般来说,JS 的操作是毫秒级,而 Go 则是纳秒级
  • 解析,生成最终打包文件和生成 source maps 的操作全部完全并行化
  • 无需昂贵的数据转换,只需很少的几步即可完成所有操作
  • 该库以提高编译速度为编写代码时的第一原则,并尽量避免不必要的内存分配。

仅作参考。

Upcoming roadmap

以下这几个 feature 已经在进行中了, 而且是第一优先级:

  1. Code splitting (#16, docs)
  2. CSS content type (#20, docs)
  3. Plugin API (#111)

下面这几个 fearure 比较有潜力, 但是还不确定:

  1. HTML content type (#31)
  2. Lowering to ES5 (#297)
  3. Bundling top-level await (#253)

感兴趣的可以保持关注。

esbuild 在 vite 中的运用

vite 中大量使用了 esbuild, 这里简单分享两点。

  1. optimizer

https://github.com/vitejs/vite/blob/main/packages/vite/src/node/optimizer/index.ts#L262

import { build, BuildOptions as EsbuildBuildOptions } from 'esbuild'

// ...
const result = await build({
    entryPoints: Object.keys(flatIdDeps),
    bundle: true,
    format: 'esm',
    external: config.optimizeDeps?.exclude,
    logLevel: 'error',
    splitting: true,
    sourcemap: true,
    outdir: cacheDir,
    treeShaking: 'ignore-annotations',
    metafile: true,
    define,
    plugins: [
      ...plugins,
      esbuildDepPlugin(flatIdDeps, flatIdToExports, config)
    ],
    ...esbuildOptions
  })

  const meta = result.metafile!

  // the paths in `meta.outputs` are relative to `process.cwd()`
  const cacheDirOutputPath = path.relative(process.cwd(), cacheDir)

  for (const id in deps) {
    const entry = deps[id]
    data.optimized[id] = {
      file: normalizePath(path.resolve(cacheDir, flattenId(id) + '.js')),
      src: entry,
      needsInterop: needsInterop(
        id,
        idToExports[id],
        meta.outputs,
        cacheDirOutputPath
      )
    }
  }

  writeFile(dataPath, JSON.stringify(data, null, 2))
  1. 处理 .ts 文件

https://github.com/vitejs/vite/commit/59035546db7ff4b7020242ba994a5395aac92802

为什么生产环境仍需打包?

尽管原生 ESM 现在得到了广泛支持,但由于嵌套导入会导致额外的网络往返,在生产环境中发布未打包的 ESM 仍然效率低下(即使使用 HTTP/2)。

为了在生产环境中获得最佳的加载性能,最好还是将代码进行 tree-shaking懒加载chunk 分割(以获得更好的缓存)。

要确保开发服务器和产品构建之间的最佳输出行为达到一致,并不容易。

为解决这个问题,Vite 附带了一套 构建优化构建命令,开箱即用。

为何 vite 不用 esbuild 打包?

虽然 esbuild 快得惊人,并且已经是一个在构建库方面比较出色的工具,但一些针对构建应用的重要功能仍然还在持续开发中 —— 特别是代码分割CSS处理方面。

就目前来说,Rollup 在应用打包方面, 更加成熟和灵活。

尽管如此,当未来这些功能稳定后,也不排除使用 esbuild 作为生产构建器的可能。

总结

esbuild 为构建提效带来了曙光, 而且 esm 的数量也在快速增加:

https://twitter.com/skypackjs/status/1113838647487287296

希望 esm 生态尽快完善起来, 造福前端。

--

今天的内容就这么多, 希望对大家有所启发。

才疏学浅,文章若有错误, 欢迎指正, 谢谢。

本文分享自微信公众号 - 前端皮小蛋(gh_e69260c16440),作者:南山皮小蛋

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-05-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 「 不懂就问 」esbuild 为什么这么快?

    esbuild 项目主要目标是: 开辟一个构建工具性能的新时代,创建一个易用的现代打包器。

    winty
  • CDN为什么这么快

    CDN全称:Content Delivery Network或Content Ddistribute Network,即内容分发网络。

    Bug开发工程师
  • WebAssembly 为什么这么快?

    WebAssembly 是一种使 JavaScript 以外的编程语言编写的代码能够在浏览器中运行的技术。所以当人们在讨论 WebAssembly 运行之快的时...

    桃翁
  • Redis 为什么这么快?

    再比如电商在大促销时,会用一些特殊的设计来保证系统稳定,扣减库存可以考虑如下设计:

    Java技术栈
  • Redis为什么这么快?

    | 作者 吴显坚,腾讯云数据库高级工程师,参与过360开源项目Pika的研发工作,现从事redis数据库研发工作。 ---- Redis服务器是一个事件驱动程...

    腾讯云数据库 TencentDB
  • Redis 为什么这么快?

    所有与 Java 相关的面试都会问到缓存的问题,基础一点的会问到什么是“二八定律”、什么是“热数据和冷数据” ,复杂一点的会问到缓存雪崩、缓存穿透、缓存预热、缓...

    CSDN技术头条
  • Go 为什么这么“快”

    ? 作者:joellwang,腾讯 CSIG 后台开发工程师 本文主要介绍了 Go 程序为了实现极高的并发性能,其内部调度器的实现架构(G-P-M ...

    腾讯技术工程官方号
  • 5G为什么这么快?

    5G之所以能有极高的速率,主要依靠4个武器:频率带宽、帧结构、调制编码、MIMO。

    鲜枣课堂
  • Redis 为什么这么快?

    Redis 是 NoSQL 数据库,key-Value 数据库,键值数据库会使用 hash 表存储值和数据。Redis 全称是 Remote Dictiona...

    王小明_HIT
  • Redis为什么会这么快?

    Redis 属于键值(key-value)数据库,键值数据库会使用哈希表存储键值和数据,其中 key 作为唯一的标识,而且 key 和 value 可以是任何的...

    MickyInvQ
  • Redis 为什么这么快?(9)

    因为单线程已经够用了,CPU不是redis的瓶颈。Redis的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现,而且CPU不会成为瓶颈,那就顺理成章地采用...

    兜兜毛毛
  • 尤雨溪:下一代前端构建工具 ViteJS 技术解读

    https://juejin.cn/post/6937176680251424775

    @超人
  • 搞不懂DMP是什么?看这里就够了

    近年来,随着移动互联网和信息时代的不断发展,大数据技术在各行各业的作用也日益显著。在营销领域,大数据技术应用从精准营销、闭环营销扩展到了消费者价值挖掘、消费者全...

    王知无-import_bigdata
  • 为什么 go 语言这么“快”?

    本文经公众号:腾讯技术工程(ID:Tencent_TEG)授权转载,如需转载请联系出处。

    范蠡
  • 大数据为什么这么快

    1、扩展性 传统的是纵向扩展(服务器数量不变,每个的配置越来越高) 大数据是横向扩展(每个的配置不变,但服务器数量越来越多) 2、分布式 传统的是集中式...

    云缓缓知我意
  • 下一代前端构建工具 ViteJS 技术解读,尤雨溪diss:Webpack!

    关于 Vite,来看看作者本人怎么说。本视频是 Vue 以及 Vite 作者 尤雨溪 在 2021 年 2 月 12 日在 Twitch 上做客 GitHub ...

    苏南
  • 不懂就问,这波虎扑diss吴亦凡属于什么水平?

    (押韵支持来自我们去年的文章 Python有嘻哈:Crossin教你用代码写出押韵的verse)

    Crossin先生
  • 为什么单线程Redis这么快

    Redis是一个开源的内存中的数据结构存储系统,它可以用作:数据库、缓存和消息中间件。

    vimsudoers
  • 为什么微信推荐这么快?

    ? 作者:sauronzhang、flashlin、fengshanliu,微信后台开发工程师 1. 背景 在一些推荐系统、图片检索、文章去重等场景中,对...

    腾讯技术工程官方号

扫码关注云+社区

领取腾讯云代金券