Elysia JIT 'compiler'와 왜 이것이 가장 빠른 JavaScript 프레임워크 중 하나인지

Source: Dev.to

Source: …

Elysia JIT “컴파일러”에서 발췌

Elysia는 빠르며, 기본 JavaScript 엔진의 속도에만 제한되는 가장 빠른 웹 프레임워크 중 하나로 남을 가능성이 높습니다.
그 속도는 특정 런타임에 대한 최적화(예: Bun.serve.routes와 같은 Bun의 네이티브 기능)뿐만 아니라 라우트 등록과 요청 처리 방식을 통해서도 달성됩니다.

JIT “컴파일러”

Elysia 0.4(2023‑03‑30)부터 코어에 src/compose.ts에 위치한 JIT “컴파일러”가 포함되었습니다.
이 컴파일러는 new Function(...)(일명 eval(...))을 사용해 정의된 라우트와 미들웨어를 기반으로 요청 처리를 위한 최적화된 코드를 동적으로 생성합니다.

이 “컴파일러”는 한 언어에서 다른 언어로 코드를 변환하는 전통적인 컴파일러가 아닙니다.
요청‑처리 전용 코드를 즉석에서 동적으로 만들어 내기 때문에 컴파일러라는 표현을 따옴표로 감쌌습니다.

특정 라우트에 대한 첫 번째 요청이 들어오면 프레임워크는 다음을 수행합니다.

1. 라우트 핸들러를 분석합니다.
2. 해당 라우트에 맞춘 최적화 코드를 생성합니다.
3. 이후 요청을 위해 생성된 코드를 캐시합니다.

Sucrose – 정적 코드 분석

JIT 컴파일러와 함께 src/sucrose.ts에 위치한 정적 분석 모듈은 별명 “Sucrose” 로 불립니다.

Sucrose:

• Function.toString()을 이용해 코드를 실행하지 않고 핸들러 코드를 읽어들입니다.
• 커스텀 패턴 매칭을 수행해 요청 중 실제로 필요한 부분(예: params, body, query 등)을 판단합니다.
• 컴파일러에 어떤 요청 컴포넌트를 파싱해야 하는지 알려줘, 불필요한 작업을 건너뛸 수 있게 합니다.

예시

import { Elysia } from 'elysia';

const app = new Elysia()
  .patch('/user/:id', ({ params }) => {
    return { id: params.id };
  });

이 핸들러에서는 params만 필요합니다.
Sucrose는 이를 감지하고 컴파일러에게 params만 파싱하도록 지시해 body, query, headers 등을 건너뛰게 합니다.

생성된 코드는 다음과 같습니다:

// Elysia – 맞춤형 핸들러
function tailoredHandler(request) {
  const context = {
    request,
    params: parseParams(request.url)   // 필요한 것만
  };

  return routeHandler(context);
}

기본적으로 모든 것을 파싱하는 전통적인 프레임워크와 비교하면:

// 전통적인 프레임워크 – 중앙 핸들러
async function centralHandler(request) {
  const context = {
    request,
    body: await parseBody(request),
    query: parseQuery(request.url),
    headers: parseHeader(request.headers),
    // …기타 내용
  };

  return routeHandler(context);
}

Elysia는 각 라우트에 필요한 최소 작업만 수행하기 때문에 지연 시간이 크게 감소합니다.

왜 커스텀 파서인가?

범용 정적 분석 도구는 Elysia의 요구에 비해 과도하며 불필요한 오버헤드를 초래합니다.
Elysia 파서는 JavaScript 문법의 아주 작은 부분—주로 함수 시그니처와 프로퍼티 접근—만 이해하면 됩니다.

이 부분을 DSL(도메인‑특정 언어) 로 취급하면 다음과 같은 장점이 있습니다:

• 작업에 맞춘 가벼운 파서를 만들 수 있다.
• 메모리 사용량을 낮게 유지한다.
• 전체 AST 기반 도구에 비해 높은 성능을 얻는다.

추가 최적화

응답 매핑

응답 처리를 위한 두 가지 작지만 영향력 있는 최적화가 존재합니다:

플랫폼‑특화 최적화

Elysia는 원래 Bun을 위해 설계되었지만 Node.js, Deno, Cloudflare Workers 등에서도 실행됩니다.
호환성이 플랫폼 최적화와는 다릅니다. Elysia는 … (이하 내용은 다음 파트에 이어집니다)

플랫폼‑특정 기능을 사용할 수 있을 때:

이러한 마이크로 최적화가 누적되어 Elysia는 목표 플랫폼에서 매우 빠른 성능을 발휘합니다.

첫 번째 요청의 오버헤드

동적 코드 생성은 라우트당 작은 일회성 비용을 도입합니다.
현대 CPU에서는 분석 및 컴파일에 일반적으로 < 0.05 ms 정도가 소요되며, 이후에는 캐시된 최적화 핸들러가 모든 후속 요청에 사용됩니다.

Performance Overview

• Overhead Reduction
  JIT 컴파일 단계는 precompile: true 를 Elysia 생성자에 설정함으로써 시작 단계로 옮길 수 있습니다. 이렇게 하면 첫 번째 요청 시 발생하는 오버헤드를 없앨 수 있지만 시작 속도가 느려지는 대가가 있습니다.

• Memory Usage
  동적으로 생성된 코드는 이후 요청을 위해 메모리에 저장됩니다. 이는 특히 라우트 수가 많은 애플리케이션에서 메모리 사용량을 증가시킬 수 있지만, 일반적으로 그 영향은 크지 않습니다.

• Bundle Size
  JIT “컴파일러”와 Sucrose 모듈이 Elysia 핵심 라이브러리에 추가 코드를 삽입하여 최종 번들 크기가 약간 늘어납니다. 실제로는 성능 향상이 이 작은 증가분을 능가하는 경우가 대부분입니다.

• Complexity & Maintainability
  동적 코드 생성은 코드베이스를 더 복잡하게 만듭니다. 유지보수자는 JIT “컴파일러”가 어떻게 작동하는지에 대한 확실한 이해가 필요하며, 이를 통해 프레임워크를 효과적으로 사용하고 문제를 해결할 수 있습니다.

• Security Considerations
  new Function(...) 혹은 eval(...) 사용은 잘못 다루면 보안 위험을 초래할 수 있습니다. Elysia는 신뢰할 수 있는 프레임워크‑생성 코드만 실행되도록 보장함으로써 이를 완화합니다; 입력은 거의 사용자가 제어하지 않으며 Sucrose 자체에 의해 생성됩니다.

• Overall Overhead
  이러한 최적화를 통해 Elysia는 거의 제로에 가까운 런타임 오버헤드를 달성합니다. 주요 제한 요인은 기본 JavaScript 엔진의 속도가 됩니다.

Trade‑offs

유지보수성 문제에도 불구하고, Elysia의 JIT “컴파일러”가 만든 트레이드‑오프는 상당한 성능 향상으로 정당화됩니다. 이는 고성능 서버를 구축하기 위한 빠른 기반을 제공한다는 목표와 일치합니다.

• 차별화
  Elysia는 성능에 중점을 두어, 속도를 동일하게 우선시하지 않는 많은 다른 웹 프레임워크와 차별화됩니다. 이 수준의 최적화를 달성하는 것은 매우 어렵습니다.

• 연구 지원
  ACM Digital Library에 실린 6페이지 분량의 짧은 연구 논문이 JIT “컴파일러”와 그 성능 최적화에 대해 자세히 설명하고 있습니다.

벤치마크 개요

• 수년에 걸쳐, Elysia는 플랫폼 전반에 걸친 벤치마크에서 지속적으로 가장 빠른 프레임워크였으며, 다만 FFI/네이티브 바인딩을 사용하는 솔루션(예: Rust, Go, Zig)과 비교할 때는 제외됩니다.
• 이러한 네이티브 바인딩은 직렬화/역직렬화 오버헤드 때문에 이기기 어렵습니다.
• uWebSockets(C++로 작성되고 JavaScript 바인딩을 가진)와 같은 일부 특수 경우는 매우 저수준 구현 덕분에 Elysia보다 성능이 뛰어날 수 있습니다.

결론

가끔씩 이상치가 있더라도, Elysia의 JIT “컴파일러”가 제공하는 성능 향상은 추가된 복잡성을 능가하며 노력할 가치가 충분히 있습니다.