블레이저 성능
아직 알파 수준이지만 블레이저를 사용하고 싶습니다.
Blazor는 클라이언트 측에서 C#을 컴파일하기 위해 웹어셈블리를 사용하는 것으로 알고 있습니다.
그리고 저는 다음과 같은 질문이 있습니다.
이 접근 방식은 JavaScript로 컴파일된 React /Vue.js와 같은 경우보다 더 빨리 실행됩니까?
페이지가 로드될 때마다 브라우저가 웹 어셈블리 라이브러리를 다운로드해야 한다는 것이 사실입니까?
인터넷에서는 인기 있는 자바스크립트 프레임워크의 성능을 비교할 수 없습니다.그래서 저는 마이크로소프트사의 새로운 프레임워크의 이론적 성능을 알고 싶습니다.
페이지가 로드될 때마다 브라우저가 웹 어셈블리 라이브러리를 다운로드해야 한다는 것이 사실입니까?
아니요, 브라우저는 파일을 캐시할 수 있습니다.Blazor 애플리케이션용 공통 CDN이 유용합니다.
이 시스템은 자바스크립트로 컴파일된 React / Vue.js와 같은 시스템보다 작동 속도가 빠릅니까?
Blazor는 WebAssembly를 사용합니다. 종이상의 WebAssembly는 어떤 JavaScript 라이브러리보다 빠를 것입니다.그러나 모든 브라우저에 아직 성숙한 웹 어셈블리 파서가 있는 것은 아닙니다.따라서 현재로서는 브라우저가 최적의 속도로 웹 어셈블리를 실행하지 않을 수 있습니다.
작은 Blazor 응용 프로그램을 만들어 Firefox, Chrome 또는 Edge에서 실행할 수 있습니다.대부분의 경우 Firefox는 Chrome 또는 Edge보다 Blazor 애플리케이션을 훨씬 더 빨리 실행하므로 브라우저 제조업체는 여전히 개선해야 하며 Firefox도 개선할 수 있습니다.
응용 프로그램이 DOM에 자주 액세스해야 하는 경우 웹 어셈블리는 호출을 사용하지 않고는 DOM에 직접 액세스할 수 없기 때문에 웹 어셈블리/Blazor는 다른 JavaScript 라이브러리에 비해 확실히 느립니다.아래의 Blazor 벤치마크를 참조하십시오.
Firefox 의경 10,000개RegisteredFunction.InvokeUnmarshalle빈 메소드에 대한 호출은 250ms가 걸리는 반면 크롬과 엣지는 내 PC에 2400ms 이상이 필요합니다.순수 자바스크립트에서는 동일한 시나리오에 대해 10밀리초 미만의 시간이 소요됩니다.
또한 Blazor의 현재 구현체는 브라우저의 Web Assembly 엔진 위에 자체 MSIL 엔진이 있습니다. 즉, Blazor 프로젝트를 실행하기 위해 일하는 두 명의 통역사가 있습니다. 마치 두 명의 통역사가 한 명의 대화를 대신 통역하는 것처럼 말입니다.현재 마이크로소프트는 아직 출시되지 않은 AOT 컴파일러를 개발하고 있습니다.일단 출시되면 Blazor는 현재 구현보다 훨씬 더 빨라질 것입니다.
우리는 웹 어셈블리가 웹 개발의 미래라고 안전하게 가정할 수 있지만, 현재로서는 Blazor의 미래에 대해 아무 말도 할 수 없습니다.문서상 Blazor는 다른 프레임워크보다 더 빠를 수 있지만, 이론을 실용화하려면 웹 어셈블리 유지보수자, 브라우저 개발자, 마이크로소프트 및 커뮤니티의 노력이 필요합니다.
2018년 7월 10일 업데이트
웹 어셈블리 리포지토리에 새 제안이 있습니다.
웹 어셈블리가 DOM을 직접 처리할 수 있습니다.인터페이스 유형 #8
GC가 있는 웹 어셈블리의 참조 유형입니다.웹 어셈블리의 참조 유형
위의 두 가지 제안은 향후 DOM과 웹 어셈블리 간의 훨씬 더 빠른 상호 작용의 길을 열어줄 것입니다.다시 말해서, 블레이저는 미래에 훨씬 더 빠를 것입니다.
2018년 10월 17일 업데이트
Firefox 팀은 JavaScript-to-JavaScript 메서드 호출만큼 빠르게 JavaScript-to-WebAssembly 호출에 도달할 수 있었습니다.현재 Firefox는 웹 어셈블리 지원과 관련하여 다른 브라우저보다 훨씬 앞서 있습니다.
JavaScript와 WebAssembly 간의 통화 속도가 드디어 빠름
2021년 4월에 당사는 레거시 Angular.js 웹 앱뿐만 아니라 Flutter Web(HTML & CanvasKit 렌더러)에 대한 Blazor WASM 평가판을 실행했습니다.기존 앱의 메인 페이지(필터, 페이지화, 정렬 등이 포함된 빅 데이터 그리드)를 다시 만들었습니다.다음은 몇 가지 유용한 정보입니다.
Lighthouse perf. Scores
Grid Displ. Data transf. Data uncomp. Reqs. FCP SI LCP TTI TBT CLS
Blazor* 2.2s 4.7MB 13.7MB 99 0.5s 1.6s 0.5s 2.1s 1.3s 0.01
Flutter HTML 1.7s 2.1MB 3.7MB 15 1.9s 2.5s 2.2s 2.3 0.2s 0
Flutter CanvasKit^ 2.8s 4.7MB 10.5MB 17 1.0s 2.2s -/- 2.2s 1s 0
AngularJS` 1.9s 2.0MB 5.7MB 294 2.1s 2.2s 2.6s 2.6s 0.1s 0
- 그리드 표시 - 거더를 완전히 표시하는 데 걸린 시간(라이트하우스에서 수집한 타임라인 및 스크린샷으로 판단)
- 데이터 전송 - 앱 로드 시 데이터 전송(DevTools의 Network 탭, 캐시 삭제)
- 데이터 압축 해제 - 전송된 데이터의 압축되지 않은 크기(네트워크 탭)
- 요청 - 앱을 로드하는 동안 실행된 요청 수(네트워크 탭, 캐시 삭제)
- 라이트하우스 성능 점수 분석
- Windows 10, Google Chrome 버전 89.0.4389.128(공식 빌드, 64비트), Intel Core i5 4460, 16GB RAM, 유선 LAN 연결에서 테스트됨
- 앱, Blazor WASM/을 빌드하는 데 사용되는 구성을 릴리스합니다.NET 5, Flooth(채널 베타, 2.1.0-12.2.pre), AngularJS 1.7.7
*라이트하우스가 잘못된 LCP 값을 제공합니다(Blazor의 공백 'Loading..LCP로 페이지)
^Flutter의 CanvasKitrender는 Lighthouse가 LCP 측정값을 가져오는 것을 허용하지 않습니다.
"기존 앱은 PoC가 생성된 것보다 훨씬 크며 앱 실행 시 요청 수에 영향을 미치는 화면과 자산이 더 많습니다.
Blazor는 클라이언트 측에서 C#을 컴파일하기 위해 웹어셈블리를 사용하는 것으로 알고 있습니다.
반은 사실입니다.코드를 WASM(Web Assembly) 클라이언트 측(예, 클라이언트 측의 C#)에 작성할 수 있지만 논리 서버 측도 실행할 수 있습니다.둘 다 이점이 있습니다.WASM 경로로 이동하면 모든 코드가 표시됩니다.그러나 논리가 모두 서버 기반인 경우보다 빠르게 렌더링할 수 있지만, 서버 기반인 경우 코드를 볼 수 없습니다.
이 접근 방식은 JavaScript로 컴파일된 React /Vue.js와 같은 경우보다 더 빨리 실행됩니까?
아니요. 저는 Vue.js를 많이 했고 Vue.js는 더 빨리 달립니다.하지만 Blazor를 사용하면 코드를 훨씬 더 빨리 작성할 수 있습니다.그리고 Blazor는 더 빨리 보이도록 하는 가상 스크롤 솔루션을 제공합니다.제 경우에는 사용 가능한 플로팅 구성 요소가 너무 느렸습니다.저는 C#과 자바스크립트를 사용하여 Blazor 구성 요소를 작성했는데 매우 잘 작동했습니다.대부분의 경우 WASM 코드가 너무 느리게 실행되는 것에 대해 걱정하지 않습니다.하지만 음모는 훨씬 더 빨라야 했습니다그리고 블레이저가 내 케이크를...자바스크립트로 낮은 수준의 작업을 해야 했습니다.지난 6개월 동안 블레이저 실행 속도가 빨라졌으며 팀은 앞으로 더 많은 작업이 있을 것이라고 말합니다.NET 6 나왔습니다.하지만 지금까지 필요한 작업의 99%를 처리할 수 있을 정도로 빠릅니다.
페이지가 로드될 때마다 브라우저가 웹 어셈블리 라이브러리를 다운로드해야 한다는 것이 사실입니까?
캐시된 경우에는 그렇지 않습니다.그리고 처음 로드할 때도 제대로 연결되어 있으면 느리지 않습니다.그것은 대략 10MB 정도입니다.
질문하지 않은 위대한 질문 -- 그것은 사용할 가치가 있습니까?저는 그것을 6개월 정도 사용하고 있습니다.
저에게 그것은 훌륭했습니다.C#는 매우 좋은 언어입니다.속성을 동적으로 추가하는 것을 놓치는 경우도 있고 자주 수동으로 다시 그리기를 시작해야 하지만, nullable 객체 검사와 같은 기능을 사용하면 코드가 null 참조 검사를 유발할 수 있는지 확인하지 않았다는 경고가 표시되므로 JavaScript보다 훨씬 좋습니다.저는 종종 자바스크립트 "툴체인"으로 작업하는 것이 고통스럽다고 느꼈습니다.자바스크립트의 라이브러리 스래시에서 벗어날 수 있어서 너무 좋습니다.
ASP.에 대한 NET Core 로드맵.NET 6은 여기 github에서 찾을 수 있습니다.당신은 블레이저가 가장 많은 일을 하고 있다는 것을 알게 될 것입니다.
목록에 ASP 항목이 표시됩니다.NET 팀은 Blazor를 개선하는 데 많은 중점을 두고 있다는 의미에 초점을 맞출 것입니다.
이번 호는 우리 팀이 중점적으로 투자할 주요 투자 목록을 나타냅니다.NET 6 시간대.이 목록에 있는 항목은 주요 투자 분야일 뿐이며, 이 기간 동안 다룰 모든 기능과 버그 수정 사항은 포함되지 않습니다.
다음은 그들이 작업해 온 몇 가지 작업입니다.
완료된 작업:
AOT 컴파일.모든 항목을 웹 어셈블리에 컴파일
Blazor의 SVG 지원을 개선합니다.Blazor의 SVG 지원에 대한 최상위 문제
JS Interop에서 바이트 배열 전송을 지원합니다.
진행 중인 작업
블레이저를 위한 뜨거운 재장전.성능 최적화 구축
Blazor 응용 프로그램을 일시 중지했다가 다시 시작합니다.
데스크톱 플랫폼을 대상으로 하여 구축합니다.
SignalR 메시지 크기에 의해 부과된 크기 제한을 제거합니다.
드래그 앤 드롭.끌어서 놓기 중에 사용자가 가입할 수 있는 이벤트 제공
기준: .net 7(2023 업데이트)
블레이저 웹사이트는 현재 생산 준비가 훨씬 더 되어 있으며, 적절한 브로틀리 압축 및 트리밍을 사용할 때 속도가 빠릅니다.이론적으로 Blazor는 WebAssembly의 성능 이점을 활용하여 브라우저에서 네이티브와 같은 성능을 달성할 수 있으므로 wasm이 직접 돔에 액세스할 수 있을 때만 볼 수 있는 고성능 애플리케이션에 적합합니다.수준에 미치지 못하지만 프론트엔드 웹 앱을 위해 c# 코드를 작성할 수 있다는 것은 마법입니다.
만약 여러분이 그것이 실제로 작동하는 것을 보는 것에 관심이 있다면, 우리의 프로젝트인 PhotosNepal.com 을 꼭 확인해 보세요. 그것은 전적으로 Blazor에 기반을 두고 만들어진 주식 이미지 웹사이트입니다.우리는 현재 결과에 만족하지만, 몇 가지 개선할 점이 있습니다.
언급URL : https://stackoverflow.com/questions/50422396/blazor-performance
'programing' 카테고리의 다른 글
| 달러 기호($"string")는 무엇을 합니까? (0) | 2023.05.11 |
|---|---|
| NODE.JS: 치명적 오류 - JS 할당 실패 - 대용량 엑셀 파일을 구문 분석하는 동안 메모리 부족 처리 (0) | 2023.05.11 |
| 오류 메시지 '_BSMachError: (os/kern) 잘못된 기능(20)' (0) | 2023.05.06 |
| ASP에서 가방을 보는 방법.NET MVC 작동 (0) | 2023.05.06 |
| PostgreSQL: 역할이 로그인할 수 없습니다. (0) | 2023.05.06 |