Yuxi님은 다음과 같이 답변하셨습니다. Vite가 정말 Turbopack보다 10배 느린가요?

원문: https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussions/8

저자: You Yuxi

일주일 전, Vercel은 Rust 기반의 Webpack을 발표했습니다. 터보팩의 후속작.

발표에서 Turbopack은 "Vite보다 10배 빠르다"고 주장합니다. 이 문구는 트윗, 블로그 게시물, Vercel 사용자에게 전송되는 마케팅 이메일 등 다양한 Vercel 마케팅 자료에서 반복됩니다. Turbopack의 문서에는 Vite의 0.09초에 비해 TurboPack이 포함된 Next.js 13이 0.01초 만에 React HMR 핫 업데이트를 수행할 수 있음을 처음에 보여준 벤치마크 그래프도 포함되어 있습니다. 콜드 스타트 ​​성능에 대한 벤치마크도 있지만 콜드 스타트 ​​속도가 Vite보다 10배 빠르다는 비교는 발견되지 않았기 때문에 '10배 빠르다'는 것은 HMR 성능을 기준으로 한 것이라고밖에 짐작할 수 없다. [관련 권장 사항: vuejs 비디오 튜토리얼, 웹 프론트 엔드 개발]

Vercel은 마케팅 자료나 문서에서 이러한 수치를 입증하는 데 사용되는 벤치마크에 대한 링크를 사용하지 않습니다. 그래서 저는 호기심이 생겨 방금 출시된 Next 13 및 Vite 3.2의 벤치마크를 사용하여 제 주장을 테스트하기로 결정했습니다. 코드와 메소드는 여기 오픈 소스입니다.

내 접근 방식의 요점은 다음 두 타임스탬프 사이의 델타를 측정하여 HMR 성능을 비교하는 것입니다.

• 소스 파일이 수정된 시간, 별도의 node.js 프로세스를 통해 파일 변경을 관찰합니다. 업데이트된 React 컴포넌트를 다시 렌더링하는 시간은 해당 컴포넌트의 render 함수에서 직접

  를 호출하여 기록됩니다. 이 호출은 구성 요소의 가상 DOM 렌더링 단계에서 발생하므로 React 조정이나 실제 DOM 업데이트의 영향을 받지 않습니다.

• Date.now()benchmark는 또한 두 가지 다른 사례에 대한 숫자를 측정했습니다.

구성 요소가 1,000개의 다른 하위 구성 요소를 가져와 함께 렌더링하는 "루트" 사례입니다.

• "리프" 경우, 이 구성 요소는 루트에서 가져오지만 자체 하위 구성 요소는 없습니다.

• 차이점

숫자로 들어가기 전에 언급할 만한 몇 가지 추가 차이점이 있습니다.

다음으로 React Server Component(RSC)를 사용할지 여부를 결정하세요.

• Vite가 React 이스케이프를 위해 Babel 대신 SWC를 사용하는지 여부.

• React Server Components

Next 13에서는 사용자가 "use-client" 지시문을 사용하여 클라이언트 모드를 명시적으로 선택하지 않는 한 구성 요소가 이제 서버 구성 요소로 기본 설정되므로 주요 아키텍처 변화가 도입되었습니다. 이것이 기본 설정일 뿐만 아니라 Next 설명서에서는 최종 사용자 성능을 향상시키기 위해 가능한 경우 서버 구성 요소 모드를 유지할 것을 사용자에게 권장합니다. 제 초기 벤치마크 테스트에서는 서버 모드에서 Next 13의 루트 및 리프 구성 요소의 HMR 성능을 측정했습니다. 결과는 실제로 Next 13이 두 경우 모두 더 느리고 리프 구성 요소의 차이가 크다는 것을 보여줍니다.

Round 1 snapshot (Next w/ RSC, Vite w/ Babel)

이 숫자를 Twitter에 게시했을 때 누군가가 RSC 벤치마크 테스트 없이 동등성을 위해 Next 구성 요소를 수행했어야 했다고 재빠르게 지적했습니다. 그래서 클라이언트 모드를 선택하기 위해 Next 루트 구성 요소에 "useclient" 지시어를 추가했습니다. 실제로 클라이언트 모드에서 Next HMR은 Vite보다 2배 더 빠르게 크게 향상되었습니다.

Round 2 스냅샷(RSC가 없는 Next, Babel이 있는 Vite)

SWC vs. Babel 변환

우리의 목표는 벤치마크가 HMR 성능 차이에만 초점을 맞추도록 하는 것입니다. 실제로 동일한 것을 비교하려면 또 다른 변수도 제거해야 합니다. Vite의 기본 React 사전 설정은 Babel을 사용하여 React HMR 및 JSX를 변환합니다.

React HMR 및 JSX 변환은 빌드 도구와 결합된 기능이 아닙니다. 이는 Babel(js 기반) 또는 SWC(rust 기반)를 통해 수행할 수 있습니다. Esbuild는 JSX도 변환할 수 있지만 HMR에 대한 지원은 부족합니다. SWC는 Babel(20x 싱글 스레드, 70x 멀티 코어)보다 훨씬 빠릅니다. Vite가 현재 Babel을 기본으로 사용하는 이유는 설치 크기와 실용성 간의 균형 때문입니다. SWC의 설치 용량은 상당히 크며(node_modules의 경우 58MB, Vite 자체의 경우 19MB에 불과) 많은 사용자가 여전히 다른 변환을 위해 Babel을 사용하므로 Babel 패스는 불가피합니다. 물론 이는 앞으로 바뀔 수도 있다.

Vite 코어는 Babel에 의존하지 않습니다. 기본 React 플러그인을 vite-plugin-swc-react-refresh로 바꾸세요. 전환 후 Next에 비해 루트 케이스에서 Vite에 비해 상당한 개선이 이루어졌습니다.

흥미롭게도 여기의 성장 곡선은 Next/turbo가 리프 케이스보다 루트 케이스에서 4배 느린 반면 Vite는 2.4배만 느린 것을 보여줍니다. . 이는 Vite HMR이 더 큰 구성 요소에서 더 나은 성능을 발휘한다는 것을 의미합니다.

또한 SWC로 전환하면 Vercel 벤치마크에서 Vite의 콜드 스타트 ​​측정 항목도 개선됩니다.

다양한 하드웨어에서의 성능

이것은 Node.js와 기본 Rust 부분을 포함하는 복합 테스트이므로 하드웨어마다 상당한 차이가 있습니다. 제가 게시한 결과는 제 M1 MacBook Pro에 수집되었습니다. 다른 사용자는 다른 하드웨어에서 동일한 벤치마크를 실행하고 다른 결과를 보고했습니다.

어떤 경우에는 루트 케이스가 있는 Vite가 더 빠릅니다.

그리고 다른 경우에는 두 경우 모두 Vite가 훨씬 더 빠릅니다.

Vercel의 설명

내가 벤치마크를 게시한 후 Vercel은 벤치마크 방법론을 명확하게 설명하고 공개 검증에 벤치마크를 제공하는 블로그 게시물을 게시했습니다. 이것은 하루의 첫 번째 일일 수 있지만 확실히 올바른 방향으로 나아가는 단계입니다.

게시물과 벤치마크 코드를 읽은 후 다음은 몇 가지 핵심 사항입니다.

• Vite 구현은 여전히 ​​기본 Babel 기반 React 플러그인을 사용합니다.

• 1k 구성 요소의 경우 반올림 문제가 있습니다. Turbopack의 15ms는 0.01s로 반올림되고 Vite의 87ms는 0.09s로 반올림됩니다. 이로 인해 원래 6배에 가까웠던 격차가 10배로 넓어졌습니다.

• Vercel의 벤치마크는 React 구성 요소 다시 렌더링 시간 대신 업데이트 모듈의 "브라우저 평가 시간"을 종료 타임스탬프로 사용합니다.

• 게시물에는 총 모듈 수가 30,000개를 초과할 때 Turbopack이 Vite보다 10배 더 빠를 수 있음을 보여주는 차트가 포함되어 있습니다.

요약하자면, "Vite보다 10배 빠르다"는 조건은 다음과 같습니다:

• Vite는 동일한 SWC 변환을 사용하지 않습니다.

• 애플리케이션에는 30k개 이상의 모듈이 포함되어 있습니다.

• 벤치마크는 변경 사항이 실제로 적용되는 때가 아니라 핫 업데이트된 모듈이 평가되는 시간만 측정합니다.

"공정한" 비교란 무엇인가요?

Vercel의 벤치마크 테스트는 React의 HMR 런타임으로 인한 차이를 제외하기 위해 "모듈 평가 시간"을 측정하므로 벤치마크 테스트의 목표는 Vite와 Turbopack의 고유 HMR 메커니즘을 공정하게 비교하는 것이라고 가정할 수 있습니다.

안타깝게도 이 전제를 고려할 때 Vite는 여전히 벤치마크 테스트에서 Babel을 사용하는데, 이는 불공평하며 10배 속도 주장을 무효화합니다. SWC 변환 Vite를 사용하여 숫자를 수정하기 전에 이는 부정확한 테스트로 간주되어야 합니다.

또한 대부분의 사람들이 동의할 것이라고 믿습니다.

• 대부분의 사용자에게 30,000개의 모듈 수는 거의 발생하지 않는 시나리오입니다. Vite가 SWC를 사용함에 따라 10x 요구 사항을 달성하는 데 필요한 모듈 수가 훨씬 더 비실용적이 될 수 있습니다. 이는 이론적으로는 가능하지만 Vercel의 지속적인 마케팅 성공을 입증하기 위해 이를 사용하는 것은 솔직하지 못할 것입니다.

• 사용자들은 이론적인 "모듈 평가" 시간보다는 엔드투엔드 HMR 성능, 즉 저장부터 변경 사항 반영까지의 시간에 더 관심을 갖습니다. "10배 더 빠른 업데이트"를 보면 일반 사용자는 후자보다는 전자를 고려할 것입니다. Vercel은 마케팅에서 이 경고를 편리하게 생략합니다. 실제로 Next의 서버 구성요소의 엔드 투 엔드 HMR(기본값)은 Vite보다 느립니다.

Vite 작성자로서 Vercel과 같이 자금이 풍부한 회사가 프런트 엔드 도구 개선에 많은 투자를 하는 것을 보게 되어 기쁩니다. 해당되는 경우 향후 Vite에서 Turbopack을 활용할 수도 있습니다. 나는 OSS 공간에서의 건전한 경쟁이 궁극적으로 모든 개발자에게 이익이 될 것이라고 믿습니다.

그러나 저는 또한 오픈 소스 소프트웨어의 경쟁은 열린 의사소통, 공정한 비교 및 ​​상호 존중을 기반으로 해야 한다고 믿습니다. 일반적으로 상업적인 경쟁에서만 볼 수 있는, 선별되고, 동료 심사를 거치지 않고, 경계선에 있는 오해의 소지가 있는 숫자를 사용하는 공격적인 마케팅을 보는 것은 실망스럽고 우려스럽습니다. OSS의 성공을 바탕으로 설립된 회사로서 Vercel이 더 잘할 수 있다고 믿습니다.

(학습 영상 공유: 기본 프로그래밍 영상)

위 내용은 Yuxi님은 다음과 같이 답변하셨습니다. Vite가 정말 Turbopack보다 10배 느린가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!