Bun과 거래는 무엇입니까?

이 기사를 우연히 발견했다면 Bun이 무엇인지 궁금할 것입니다. Bun에 대해 알아야 할 모든 것을 알려드리려고 합니다.

그래서 번은 무엇입니까? 기본적으로 Node.js와 유사한 새로운 JS 런타임입니다. 그러나 Node와 달리 Bun은 엄청나게 빠릅니다. 심각하게, 심각하게 빠릅니다. 나중에 살펴보겠지만 먼저 Node의 기존 문제를 살펴보겠습니다.

노드에 무슨 문제가 있나요?

Node는 2009년부터 있었습니다. 그 이후로 웹과 서버 생태계는 크게 바뀌었습니다. Node의 많은 문제는 제작자인 Ryan Dahl( )이 다루었습니다. 빠른 핵심 요약은 Node가 내장 TypeScript, JSX 또는 환경 변수를 지원하지 않는다는 것입니다. 또한 패키지 관리자인 NPM은 node_modules of doom 폴더로 유명합니다.

어떻게 그렇게 빠릅니까?

Bun은 수동 메모리 관리 기능이 있는 저수준 프로그래밍 언어인 Zig로 제작되었습니다. Google의 V8 엔진보다 약간 더 성능이 좋은 JavaScriptCore 엔진을 사용합니다.

Bun은 대부분 Zig의 속도를 인정하며 Zigwebsite에 다음과 같이 말합니다.

Zig’s low-level control over memory and lack of hidden control flow makes it much simpler to write fast software.

벤치마크

Jarred Sumner는 Node 및 Deno와 비교하여 Bun의 속도와 관련하여 Twitter에서 수많은 벤치마크를 만들었습니다. 아래에서는 Bun이 실제로 이러한 다른 런타임에 적합한지 확인하기 위해 몇 가지 테스트를 로컬에서 실행할 것입니다. 각 테스트에서 스크립트는 단순히 텍스트 파일을 로컬에 저장합니다. 속도를 테스트하기 위해 Mitata를 사용하고 있습니다.

테스트 롤빵

// ./scripts/bun.js

import { write } from "bun";
import { bench, run } from "mitata";

const file = "./out/bun.txt";

bench("bun:write", async () => {
    await write(file, "hello world");
})

await run();

➜  bench bun ./scripts/bun.js
cpu: Apple M1
runtime: bun 0.1.6 (arm64-darwin)

benchmark      time (avg)             (min … max)       p75       p99      p995
------------------------------------------------- -----------------------------
bun:write   76.86 µs/iter    (64.79 µs … 2.35 ms)   75.5 µs 139.38 µs 246.17 µs

테스트 노드

// ./scripts/node.mjs

import { writeFileSync } from "fs";
import { bench, run } from "mitata";

const file = "./out/node.txt";

bench("node:write", async () => {
    writeFileSync(file, "hello world");
})

await run();

➜  bench node ./scripts/node.mjs
cpu: Apple M1
runtime: node v18.7.0 (arm64-darwin)

benchmark       time (avg)             (min … max)       p75       p99      p995
-------------------------------------------------- -----------------------------
node:write   94.55 µs/iter   (65.92 µs … 29.59 ms)  78.29 µs 129.25 µs 217.13 µs

데노 테스트

// ./scripts/deno.mjs

import { bench, run } from "https://esm.run/mitata";

const file = "./out/deno.txt";

bench("deno:write", async () => {
    Deno.writeTextFileSync(file, "hello world");
})

await run();

➜  bench deno run -A ./scripts/deno.mjs
Download https://cdn.jsdelivr.net/npm/fs/+esm
cpu: Apple M1
runtime: deno 1.24.2 (aarch64-apple-darwin)

benchmark       time (avg)             (min … max)       p75       p99      p995
-------------------------------------------------- -----------------------------
deno:write  110.66 µs/iter    (74.25 µs … 5.88 ms) 129.79 µs 162.33 µs 179.75 µs

세 번 모두 스토리지에 파일이 기록되었습니다. 아래는 사용된 런타임, 사용된 기본 API 및 최종 속도를 포함하는 표입니다.


실행 시간
API
평균 속도


혈액 요소 질소
Bun.write()
76.86µs

마디
fs.writeFileSync
94.55µs

데노
Deno.writeTextFileSync
110.66µs


보시다시피 Bun은 서버 측 작업 측면에서 Node와 Deno보다 분명히 앞서 있습니다. Bun은 클라이언트 측 작업을 사용할 때 잘 작동하지 않기 때문에 서버 측 작업이라고 말합니다. 다음 게시물에서는 Bun + Next.js를 Deno + Fresh와 비교할 것입니다.

또한 Bun이 아직 개발 중이라는 빠른 알림입니다. 이 게시물에서 본 내용은 몇 개월 후에는 관련이 없을 수 있습니다. 명심하십시오.

어쨌든 이 글이 도움이 되셨기를 바랍니다 😄

공유 + 팔로우를 고려해 주세요