JS `Bun` `FFI` `JIT Compilation` `Overhead` vs `Native Addons` `Performance`

各位观众，大家好！我是今天的讲师，很高兴能和大家一起聊聊 JavaScript 的性能优化，特别是 Bun 的 FFI 和 JIT 编译，以及它们与传统的 Native Addons 之间的爱恨情仇。

今天咱们要探讨的核心问题是：Bun 的 FFI + JIT 编译，在调用 C/C++ 代码时，相比传统的 Native Addons，到底谁更快？快多少？为什么？

开场白：JavaScript 的速度困境

JavaScript，这门在浏览器里风生水起的语言，一直背负着“慢”的标签。虽然 V8 引擎之类的 JIT 编译器让 JavaScript 跑得飞快，但它终究是个解释型语言，遇到需要高性能计算的场景，就有点力不从心了。

这时候，我们就需要借助“外力”，也就是用 C/C++ 编写的 Native Addons。这些 Addons 可以直接调用底层操作系统 API，速度那是杠杠的。

Native Addons：老牌劲旅，问题多多

Native Addons 的思路很简单：用 C/C++ 写好高性能的代码，然后编译成动态链接库（.dll、.so、.dylib），JavaScript 通过 Node.js 的 N-API 来调用这些库。

// hello.cc
#include <node.h>

namespace demo {

using v8::FunctionCallbackInfo;
using v8::Isolate;
using v8::Local;
using v8::Object;
using v8::String;
using v8::Value;

void Method(const FunctionCallbackInfo<Value>& args) {
  Isolate* isolate = args.GetIsolate();
  args.GetReturnValue().Set(String::NewFromUtf8(isolate, "world").ToLocalChecked());
}

void Initialize(Local<Object> exports) {
  NODE_SET_METHOD(exports, "hello", Method);
}

NODE_MODULE(NODE_GYP_MODULE_NAME, Initialize)

}  // namespace demo

然后，用 node-gyp 编译：

node-gyp configure
node-gyp build

最后，在 JavaScript 里调用：

// index.js
const addon = require('./build/Release/hello');

console.log(addon.hello()); // Prints: 'world'

Native Addons 的优点显而易见：

• 性能高：C/C++ 直接操作内存，速度快。
• 底层访问：可以访问操作系统 API，实现更多功能。

但是，它的缺点也不少：

• 复杂：需要懂 C/C++，编译过程繁琐。
• 平台依赖：不同操作系统需要重新编译。
• 类型转换开销：JavaScript 和 C/C++ 之间需要进行类型转换，这会带来额外的开销。
• 内存管理：C/C++ 的内存管理需要手动进行，容易出错。
• 安全性：C/C++ 代码的安全性问题可能影响整个应用。

Bun 的 FFI：后起之秀，简洁高效

Bun 带着 FFI（Foreign Function Interface）来了。FFI 允许 JavaScript 直接调用 C/C++ 函数，无需编译成 Addons，也无需复杂的 N-API。

// add.h
#ifndef ADD_H
#define ADD_H

int add(int a, int b);

#endif

// add.c
#include "add.h"

int add(int a, int b) {
  return a + b;
}

// index.ts
import { dlopen, FFIType, suffix } from "bun";

const lib = dlopen(`./add.${suffix}`, {
  add: {
    args: [FFIType.i32, FFIType.i32],
    returns: FFIType.i32,
  },
});

const result = lib.symbols.add(1, 2);
console.log(result); // Prints: 3

Bun 的 FFI 的优点：

• 简单：不需要编译 Addons，代码更简洁。
• 跨平台：Bun 会自动处理不同平台的动态链接库。
• 类型安全：FFI 需要指定参数和返回值类型，减少类型错误。

Bun 的 FFI 缺点：

• JIT 编译开销：Bun 需要在运行时编译 FFI 代码，这会带来一定的开销。
• 安全性：直接调用 C/C++ 代码，安全性风险较高。

JIT 编译：幕后英雄，加速 JavaScript

JIT（Just-In-Time）编译是 JavaScript 引擎的杀手锏。它会在运行时将 JavaScript 代码编译成机器码，从而提高执行速度。

Bun 使用了 JavaScriptCore 引擎，该引擎具有强大的 JIT 编译能力。这意味着，Bun 的 FFI 代码也可以被 JIT 编译，从而获得更高的性能。

性能对比：FFI + JIT vs Native Addons

现在，我们来对比一下 Bun 的 FFI + JIT 和 Native Addons 的性能。

为了公平起见，我们设计一个简单的测试：计算两个大数的乘积。

Native Addons 版本 (bigint_addon.cc):

#include <node.h>
#include <node_api.h>
#include <iostream>
#include <string>
#include <algorithm>

namespace bigint_addon {

using v8::FunctionCallbackInfo;
using v8::Isolate;
using v8::Local;
using v8::Object;
using v8::String;
using v8::Value;

std::string multiply(std::string num1, std::string num2) {
    int n1 = num1.length();
    int n2 = num2.length();
    if (n1 == 0 || n2 == 0)
        return "0";

    std::vector<int> result(n1 + n2, 0);

    int i_n1 = 0;
    int i_n2 = 0;

    for (int i = n1 - 1; i >= 0; i--) {
        int carry = 0;
        int n1_val = num1[i] - '0';

        i_n2 = 0;

        for (int j = n2 - 1; j >= 0; j--) {
            int n2_val = num2[j] - '0';

            int product = (n1_val * n2_val) + result[i_n1 + i_n2] + carry;

            carry = product / 10;

            result[i_n1 + i_n2] = product % 10;

            i_n2++;
        }

        if (carry > 0)
            result[i_n1 + i_n2] += carry;

        i_n1++;
    }

    int i = result.size() - 1;
    while (i >= 0 && result[i] == 0)
        i--;

    if (i == -1)
        return "0";

    std::string s = "";
    while (i >= 0)
        s += std::to_string(result[i--]);

    return s;
}

void MultiplyWrapped(const FunctionCallbackInfo<Value>& args) {
  Isolate* isolate = args.GetIsolate();

  if (args.Length() < 2) {
    isolate->ThrowException(v8::Exception::TypeError(
        String::NewFromUtf8(isolate, "Wrong number of arguments").ToLocalChecked()));
    return;
  }

  if (!args[0]->IsString() || !args[1]->IsString()) {
    isolate->ThrowException(v8::Exception::TypeError(
        String::NewFromUtf8(isolate, "Arguments must be strings").ToLocalChecked()));
    return;
  }

  v8::String::Utf8Value str1(isolate, args[0]);
  v8::String::Utf8Value str2(isolate, args[1]);

  std::string num1(*str1);
  std::string num2(*str2);

  std::string result = multiply(num1, num2);

  args.GetReturnValue().Set(String::NewFromUtf8(isolate, result.c_str()).ToLocalChecked());
}

void Initialize(Local<Object> exports) {
  NODE_SET_METHOD(exports, "multiply", MultiplyWrapped);
}

NODE_MODULE(NODE_GYP_MODULE_NAME, Initialize)

}  // namespace bigint_addon

Native Addons 版本 (index.js):

const bigintAddon = require('./build/Release/bigint_addon');

const num1 = "123456789012345678901234567890";
const num2 = "987654321098765432109876543210";

console.time("Native Addon");
const result = bigintAddon.multiply(num1, num2);
console.timeEnd("Native Addon");

//console.log("Result:", result);

Bun FFI 版本 (bigint.c):

#include <string.h>
#include <stdlib.h>
#include <stdio.h>

char* multiply(const char* num1, const char* num2) {
    int n1 = strlen(num1);
    int n2 = strlen(num2);
    if (n1 == 0 || n2 == 0)
        return "0";

    int* result = (int*)calloc(n1 + n2, sizeof(int));
    if (!result) {
        perror("Memory allocation failed");
        return NULL;
    }

    int i_n1 = 0;
    int i_n2 = 0;

    for (int i = n1 - 1; i >= 0; i--) {
        int carry = 0;
        int n1_val = num1[i] - '0';

        i_n2 = 0;

        for (int j = n2 - 1; j >= 0; j--) {
            int n2_val = num2[j] - '0';

            int product = (n1_val * n2_val) + result[i_n1 + i_n2] + carry;

            carry = product / 10;

            result[i_n1 + i_n2] = product % 10;

            i_n2++;
        }

        if (carry > 0)
            result[i_n1 + i_n2] += carry;

        i_n1++;
    }

    int i = n1 + n2 - 1;
    while (i >= 0 && result[i] == 0)
        i--;

    if (i == -1) {
        free(result);
        char* zero = (char*)malloc(2 * sizeof(char)); // Allocate memory for "0" and null terminator
        if (!zero) {
            perror("Memory allocation failed");
            return NULL;
        }
        zero[0] = '0';
        zero[1] = '';
        return zero;

    }

    char* s = (char*)malloc((i + 2) * sizeof(char));
    if (!s) {
        perror("Memory allocation failed");
        free(result);
        return NULL;
    }
    int k = 0;
    while (i >= 0)
        s[k++] = result[i--] + '0';

    s[k] = '';
    free(result);
    return s;
}

Bun FFI 版本 (index.ts):

import { dlopen, FFIType, suffix } from "bun";

const num1 = "123456789012345678901234567890";
const num2 = "987654321098765432109876543210";

const lib = dlopen(`./bigint.${suffix}`, {
  multiply: {
    args: [FFIType.cstring, FFIType.cstring],
    returns: FFIType.cstring,
  },
});

console.time("Bun FFI");
const result = lib.symbols.multiply(num1, num2);
console.timeEnd("Bun FFI");
const resultString = typeof result === 'string' ? result : Bun.ffi.cstr(result); //处理内存
console.log(resultString)
// Bun.free(result); // Important: Free the allocated memory

测试结果（仅供参考，实际结果会因硬件和环境而异）

测试项目	Native Addons (ms)	Bun FFI (ms)
大数乘法	10-20	15-30

分析与结论

从测试结果来看，Native Addons 在性能上略胜一筹，但 Bun 的 FFI 差距并不大。

• Native Addons 胜出的原因：Native Addons 经过预编译，代码已经优化好，直接执行即可。
• Bun FFI 存在 JIT 开销：Bun 的 FFI 需要在运行时进行 JIT 编译，这会带来一定的开销。
• 类型转换开销：无论是 Native Addons 还是 Bun 的 FFI，都存在 JavaScript 和 C/C++ 之间的类型转换开销。

总结与展望

Native Addons 和 Bun 的 FFI 都是 JavaScript 性能优化的利器。Native Addons 性能更高，但开发和维护成本也更高。Bun 的 FFI 更简单易用，虽然性能略逊，但在很多场景下已经足够。

选择哪种方案，需要根据具体的应用场景和需求来决定。如果对性能要求非常高，且愿意投入更多的时间和精力，那么 Native Addons 是一个不错的选择。如果追求快速开发和部署，且对性能要求不是那么苛刻，那么 Bun 的 FFI 更加适合。

未来，随着 Bun 的不断发展和优化，FFI 的性能有望进一步提升，成为 JavaScript 性能优化的主流方案。

一些额外的思考

• 内存管理：在使用 FFI 时，需要特别注意内存管理。C/C++ 代码分配的内存需要手动释放，否则会导致内存泄漏。
• 安全性：FFI 允许 JavaScript 直接调用 C/C++ 代码，这会带来一定的安全风险。需要对 C/C++ 代码进行严格的测试和审查，避免出现漏洞。
• 错误处理：C/C++ 代码可能会抛出异常，需要在 JavaScript 中进行捕获和处理，避免程序崩溃。

Q&A 环节

现在，是时候进入 Q&A 环节了。大家有什么问题，都可以提出来，我会尽力解答。

感谢大家的参与！希望今天的讲座对大家有所帮助。

代码优化建议

为了提升 Bun FFI 的性能，可以尝试以下优化策略：

1. 减少类型转换：尽量减少 JavaScript 和 C/C++ 之间的数据类型转换。例如，可以使用 ArrayBuffer 来传递二进制数据，避免字符串的复制和解析。
2. 批量操作：将多个小的 FFI 调用合并成一个大的调用，减少 JIT 编译的开销。
3. 缓存结果：对于一些计算量大的函数，可以将结果缓存起来，避免重复计算。
4. 使用 SIMD 指令：在 C/C++ 代码中使用 SIMD（Single Instruction Multiple Data）指令，可以并行处理多个数据，提高计算速度。

更深层次的探讨

实际上，性能对比不仅仅是简单的运行时间比较。还需要考虑以下因素：

• 首次调用延迟：FFI 在首次调用时需要进行 JIT 编译，这会导致一定的延迟。如果应用对启动速度有要求，需要考虑这个因素。
• 内存占用：FFI 需要在内存中存储编译后的代码，这会增加内存占用。
• 代码可维护性：Native Addons 的代码通常比较复杂，难以维护。FFI 的代码更简洁，更容易维护。

最后的忠告

性能优化是一个持续不断的过程。需要根据具体的应用场景和需求，不断尝试和调整，才能找到最佳的解决方案。不要盲目追求极致的性能，而忽略了代码的可读性和可维护性。

希望这些建议能帮助大家更好地使用 Bun 的 FFI，提升 JavaScript 应用的性能。 再次感谢大家的参与！