js-framework-benchmark - 속도의 수학적 문제에 대한 이상적인 솔루션의 변형 또는 이것이 표준인 이유

안녕하세요 여러분! 저는 js-framework-benchmark 저장소에서 속도 문제를 해결하는 데 2.5년을 보냈고, 최근에 발견한 매우 흥미로운 관찰이 있기 때문에 후회하지 않습니다.

기본적으로 모든 프레임워크 개발자와 라이브러리 개발자는 웹 개발 초기 단계에서 속도 문제에 직면하게 됩니다. 사람들이 UI에서 데이터 변경 사항을 더 빨리 볼수록 소비하는 시간이 줄어들기 때문에 이것이 가장 중요합니다. 사이트가 10% 더 빠르게 작동한다면 수십억 명의 사람들이 수년의 생명을 구할 수 있다고 상상해 보십시오.

뭔가 조치를 취해야 했기 때문에 어쩌면 다른 이유로 인해 최신 프레임워크와 라이브러리의 벤치마크를 갖춘 많은 저장소가 생성되었습니다. 이러한 저장소 중 하나는 js-framework-benchmark입니다. 여기에는 UI 제작을 위한 거의 모든 인기 프레임워크와 라이브러리가 포함되어 있습니다.

주된 작업은 데이터에 의존하는 테이블을 그리는 것입니다. 이는 간단한 작업처럼 보이지만 실제로는 애플리케이션이 무엇이든 보일 수 있지만 구성 요소, DOM의 시퀀스가 ​​브라우저와 함께 작동하고 기타 사항 - 일반 사이트의 동작을 모방합니다. 표의 한 줄, 페이지의 헤더 등은 일반적으로 전체의 한 구성요소이기 때문입니다.

애플리케이션이 코드와 시간을 종속성으로 사용하여 정상적으로 작동하므로(디스플레이, 색상은 고려하지 않습니다. 연결 시 0과 1이라고 말할 수 있으므로 이러한 종속성은 2개만 있습니다) 그런 다음 최소 1개의 구성 요소, 서로 다르게 얽힌 최소 백만 개의 구성 요소-모든 것이 하나의 엔진에 있기 때문에 특별한 의미는 없습니다. 따라서 여기서는 단순함이 명확성 때문에 적합합니다.

그래서 우리에게는 과제가 있지만 어떻게든 해결해야 합니다. 프로그래밍은 하나의 수학적 문제를 백만 가지 방법으로 해결할 수 있기 때문에 좋습니다. 그러나 가장 중요한 점은 기본적인 이상적인 알고리즘은 모든 사람에게 동일하다는 것입니다. 이는 정리이며 무엇을 어떻게 구현하는지는 취향과 편의성의 문제입니다.

이제 인터페이스를 살펴보겠습니다. 인터페이스는 어떻게 생겼나요?

테스트 앱:

일부 결과:
https://krausest.github.io/js-framework-benchmark/2024/table_chrome_130.0.6723.58.html

상태가 변경될 때 발생할 수 있는 테이블의 다양한 주요 작업에 대한 결과가 있습니다. 작업 속도를 측정하고 어떤 코드가 더 빠르게 작동하고 어떤 코드가 느리게 작동하는지 비교할 수 있습니다. 이는 모든 프레임워크와 라이브러리에 대해 공평한 경쟁의 장을 만들기 때문에 매우 편리합니다. 하지만 속도만 문제라면 괜찮겠지만, 구조 자체의 기준도 정해져 있기 때문에 정확해야 하기 때문이다. 구성 요소 접근 방식, 주요 구현, 상태 및 기타 용어가 이 모든 것에 포함됩니다. 그러한 표준이 없으면 이것은 단순히 작업 주제가 아닙니다.

따라서 표준은 프레임워크와 라이브러리 제작자에 의해 오랫동안 설정되어 왔으며 이를 수행하는 사람들에게는 분명하고 이해할 수 있습니다. 문제는 이제 UI가 빠르게 렌더링되도록 빠른 작업을 위해 이 모든 것을 어떻게든 조정해야 한다는 것입니다.

그래서 "큰" 프레임워크와 라이브러리의 모든 제작자와 자신의 손을 시험해보고 싶은 열성팬을 모으는 멋진 아이디어입니다. 스포츠와 마찬가지로 커뮤니티가 있고 문제에 대한 다양한 솔루션이 게시되는 "리더"위원회가 있기 때문에 이 모든 것이 중요합니다. 이는 단지 수학이기 때문에 프로그래밍 측면에서 그다지 좋은 비교는 아니지만 아이디어 자체는 흥미롭습니다. 왜냐하면 사람들이 아름답고 빠르게 작업을 수행하도록 유도하고 가장 중요한 것은 정확하기 때문입니다.

그런 커뮤니티는 최근 몇 년간 현재와 미래의 모든 크리에이터가 사용할 수 있는 멋진 솔루션을 많이 만들어냈습니다. 기본 알고리즘이 이미 작성되어 있으므로 바퀴를 다시 만들 필요가 없습니다. 이러한 이해를 통해 많은 시간을 절약할 수 있습니다.

많은 개발자가 이미 이상적인 코드 구현의 예를 작성했으며 이를 기반으로 하는 것은 매우 쉽습니다. 따라서 가장 좋은 점은 이전에는 이런 일이 발생하지 않았으며 무엇보다도 이 저장소 때문에 발생했다는 것입니다. 누가 뭐래도 멋있어요.

구성 요소별로 이상적인 알고리즘을 고려하면 주요 구현 알고리즘(최장 증가 하위 시퀀스 또는 다른 변형 사용), 템플릿 복제, 직접 반응성(textContent, addEventListener, classList.add)을 강조할 수 있습니다. 오늘날 쓸모없는 VDOM을 사용하는 것은 템플릿 측면에서 필요하지만 상태 작업 및 구성 요소 간 가져오기 작업과 함께 마지막 2개는 논쟁의 여지가 있습니다. 하지만 이것이 기본이며 여기서는 다른 어떤 것도 발명할 수 없습니다.

벤치마크 저장소에 코드가 많기 때문에 이 기사에는 그러한 코드가 포함되어 있지 않습니다.

어쨌든 오늘날 우리는 이미 데이터를 표시하기 위한 이상적인 코드를 가지고 있으므로 이를 고려하고 이를 기반으로 새로운 작업을 수행할 가치가 있다는 사실을 사람들이 곧 이해하기를 바랍니다. 오늘날 많은 라이브러리와 프레임워크는 훨씬 더 빠르고 효율적으로 작동할 수 있습니다. 레거시 코드에서는 이를 허용하지 않습니다. 왜냐하면 많은 작업이 있을 수 있고 모든 것을 다시 실행하지 않고도 일반적으로 가능하다는 것이 사실이 아니기 때문입니다.

위 내용은 js-framework-benchmark - 속도의 수학적 문제에 대한 이상적인 솔루션의 변형 또는 이것이 표준인 이유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!