그거 이상 하네. 당신의 노드 버전은 무엇입니까?

@PatSmuk360 3.10.0의 메모리 프로필을 테스트하고 가져와서 다른지 확인할 수 있습니까?

최신 버전의 10(10.16.3)을 실행하고 있습니다.

이전 힙 스냅샷:

다음 이후의 힙 스냅샷:

또한 Node 12.10.0에서 시도했는데 순차 빌드의 한 지점에서 587MB의 메모리 사용량에 도달하여 훨씬 더 나빠 보입니다.

이전 CPU 프로필:
CPU-20190916T133934.cpuprofile.zip

다음 이후의 CPU 프로필:
CPU-20190916T134917.cpuprofile.zip

@PatSmuk360 따라서 길고 짧은 것은 해당 버전의 차이점은 코드베이스가 ES6 구문으로 변환되었다는 것입니다. 이는 기술적으로 주요 변경 사항이 아니므로 주요 버전이 아닙니다.

하지만... 내 의심은 객체/배열 확산 구문과 같은 것에 대한 일부 Babel 변환이 더 장황한 ES5 버전보다 덜 효율적이라는 것입니다. 원래 Node 6 이상과 호환되는 트랜스파일 패키지를 내보내고 있었지만 클래스 구문을 처리할 수 없는 특정 라이브러리와의 통합이 중단 되었기 때문에 3.10.0을 테스트할 수 있는지 묻는 이유입니다. 그래서 클래스 구성이 없는 노드 4로 이동했습니다.

어떤 ES5 변환이 제대로 수행되지 않는지 정확히 파악할 수 있다면 이론적으로 더 성능이 좋은 내보내기로 이러한 Babel 내보내기 설정을 더 세분화할 수 있습니다.

@PatSmuk360 덧붙여서, 시간이 많이 걸리는 그 split 함수는 무엇입니까?

@matthew-dean String.prototype.split 것 같습니다. chrome devtools에서 프로필을 열면 모든 데이터가 색상으로 구분된 것을 볼 수 있습니다. 병목 현상을 검사하기 쉽도록 프로필을 https://cdn.jsdelivr.net/npm/[email protected]/dist/less.cjs.js 소스로 링크하도록 변경하려고 합니다. *.cjs.js ~ *.js 파일에 사용할 수 있는 소스 맵이 있습니까? https://cdn.jsdelivr.net/npm/[email protected]/dist/less.min.js.map 파일은 .min 파일을 ES6 소스에 매핑하는 것 같습니다. 번역이 병목 현상을 일으키는 위치를 파악할 수 있도록 소스 맵을 개발 도구에 제공할 수 있습니다.

특정 https://github.com/less/less.js/blob/cae5021358a5fca932c32ed071f652403d07def8/lib/less/source-map-output.js#L78의 이 줄은 CPU 시간이 많은 것 같습니다. 그러나 그것이 수행하는 작업을 고려할 때 그것은 나에게 적절하지 않은 것 같습니다.

힙 프로필에 대한 경험이 많지는 않지만 눈에 띄는 것은 (closures), (system), (array), system / Context 의 양이 증가한 것입니다. 이를 CPU 프로필에 연결하려고 하면 이러한 개체의 증가로 인해 가비지 수집에 소요되는 시간이 크게 증가하는 것으로 보입니다.

@kevinramharak 일반적으로 _n_ 깊이의 Less와 같은 AST를 CSS와 같은 직렬화되고 평평한 출력 트리로 변환하려면 많은 임시 개체 생성이 필요합니다. 따라서 어떤 일이 일어날 수 있는지는 특정 변환으로 인해 추가 _x_량의 개체가 추가된다는 것입니다. 일시적으로라도 각 노드가 2-3배의 객체를 생성하는 기하급수적 효과를 얻을 수 있습니다. 여기에 노드 수를 곱하고 규칙을 평면화해야 하는 횟수를 곱하면... 더해지는 것을 볼 수 있습니다. ES6 구문을 본질적으로 ES5 구문의 구문 설탕으로 본질적으로 생각하는 것은 일반적으로 순진했을 것입니다. (JavaScript 개발자는 일반적으로 이에 대해 유죄입니다.) 실제로 새로운 구문을 변환하면 성능이 좋지 않은 ES5 패턴이 생성될 수 있습니다. 99%의 개발자에게 이것은 큰 문제가 아닙니다. 왜냐하면 그들은 해당 코드를 초당 수백 또는 수천 번 반복하지 않기 때문입니다. 그러나 이것은 다른 주요 변경 사항이 없었기 때문에 무슨 일이 일어나고 있는지에 대한 제 추측입니다.

@kevinramharak Re: 소스 라인 - 이는 원래 Less 파서가 입력의 행/열을 추적하지 않기 때문입니다. 따라서 소스 매핑이 추가되었을 때 원본에 매핑하는 방법을 파악하기 위해 기본적으로 입력을 행으로 청크해야 했습니다. 원천. 이것은 4.x+에서 문제가 되지 않을 것이지만, 그것이 왜 그것이 지금 거기에서 많은 시간을 보내는지 이해가 됩니다.

브라우저에서 less.min.js를 사용하고 있으며 3.10.3은 이전에 사용했던 2.7.3보다 2배 느립니다. 크롬과 파이어폭스 둘 다.

@PatSmuk360 이 지점을 확인할 수 있습니까? https://github.com/matthew-dean/less.js/tree/3.11.0

요컨대, Babel의 ES5로의 변환은 다소 끔찍하며 클래스를 변환하기 위해 수많은 Object.defineProperty 호출을 사용합니다. 나는 함수 프로토타입의 출력이 훨씬 더 나은 TypeScript로 변환을 전환했습니다.

이것은 모두 훌륭하고 멋집니다. 그러나 이렇게 한 후 Less의 브라우저 테스트는 매우 오래되고 오래된 PhantomJS를 사용하기 때문에 실행되지 않으며 지금까지 아무도(저를 포함하여) PhantomJS에서 테스트를 성공적으로 마이그레이션할 수 없었습니다. 헤드리스 크롬에.

그러나 한 번에 한 가지 문제가 있습니다. 해당 분기의 dist 소스에 메모리 문제가 없으면 브라우저 테스트라는 혼란을 해결할 수 있습니다.

Less 브라우저 테스트를 Headless Chrome으로 마이그레이션하는 데 성공했지만 성능/안정성 측면에서 변환 파이프라인을 Babel에서 TypeScript로 완전히 변경하기 때문에 안전하게 병합하기 전에 사용자로부터 많은 피드백이 필요합니다.

현재 분기는 https://github.com/less/less.js/pull/3442 에서 찾을 수 있습니다.

여전히 2.7보다 2배 느립니다.

@alecpl 좋은 정보지만 3.11.0이 3.10보다 개선되었는지 알고 싶습니다.

이것에 대한 이상한 점은 _이론상으로_ 원래 Less 코드가 Babel의 반대가 되어야 하는 Lebab으로 변환되었다는 것입니다. 이는 ES5 -> ES6 -> ES5가 거의 동일해야 한다는 것을 의미하지만 분명히 그렇지 않습니다. 따라서 ES6->ES5 코드가 원래 ES5 코드와 어떻게 다른지 조사해야 합니다.

@alecpl

그래서 저는 다양한 테스트를 실행했고 Headless Chrome에서 3.11.0 vs. 3.10.3 vs. 3.9.0 vs. 2.7.3의 벤치마킹을 하는 데 시간을 보냈습니다.

Less 컴파일러가 2배 느린 것은 고사하고 모든 버전에서 더 느리다는 증거를 찾지 못했습니다. 3.10.0이 변환 설정으로 인해 메모리 오버헤드가 더 많다는 사실이 여전히 사실일 수 있으며, 시스템이 공간에 제약을 받고 결과적으로 더 많은 메모리 스왑 또는 더 많은 GC를 수행하는 경우 속도가 느려질 수 있습니까? 하지만 확인할 수 없습니다.

3.11.0 브랜치에서 grunt benchmark 를 실행하는 자신을 테스트할 수 있습니다. 그들은 개별 실행에서 다른 수치를 보고할 수 있지만 충분한 시간을 실행하면 시간이 거의 동일하다는 것을 알 수 있습니다. 그래서 나는 당신이 당신의 데이터를 얻는 곳을 모릅니다.

@PatSmuk360 3.11.0 의 메모리 오버헤드를 테스트할 수 있습니까?

나는 당신의 코드를 직접 작성하지 않습니다. 나는 nodejs를 사용하지 않습니다. 내가 언급한 두 가지 버전의 dist 폴더에서 less.min.js 파일을 가져와서 내 페이지에서 사용합니다. 그런 다음 콘솔에서 Less 코드로 인쇄된 타이밍을 봅니다. 내 적은 코드는 여러 파일을 사용하고 출력 파일은 약 100kB의 축소된 CSS입니다. 그것이 "실생활" 벤치마크입니다. Roundcube 코드에 대해 이야기하고 있습니다.

Chrome은 Firefox보다 훨씬 빠르지만 두 버전의 차이점은 비슷합니다.

@alecpl 흠.... 특정 Less 코드에 대한 특별한 차이점일 수 있습니다. 기준이 자의적인 것이 사실입니다. 시간이 있다면 그 Less 파일을 벤치마킹에 추가하겠습니다.

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

빠른 업데이트를 게시하고 싶었습니다. 3.11.1을 시도했지만 3.10.3만큼 느렸습니다. 이것을 테스트/프로파일링하기 위한 대표적인 벤치마크를 만들 수 있는지 알아보겠습니다.

3.11.1로 업그레이드했으며 현재 동일한 메모리 소비 문제가 있습니다.
적당한 크기의 프로젝트는 webpack 및 less-loader 통해 빌드하는 데 ~600MB RAM을 사용합니다.

힙 할당 타임라인을 사용하여 결과를 얻었습니다.

Ruleset 의해 유지되는 엄청난 할당량이 발생하고 있습니다.

[편집하다]
3.9로 다운그레이드하고 거기에서 힙 할당 타임라인을 가져옵니다. 근본적으로 다른 점을 발견했는지 확인하려고 합니다.

@matthew-dean
힌트를 찾았습니다.

3.11에서 RuleSet에 대해 나열된 보유자 중 하나는 ImportManager입니다.
3.9에서는 _그렇지 않습니다_.

모든 것이 ImportManager에 의해 활성 상태로 유지되고 ImportManager는 전체 컴파일 프로세스에서 단일 항목입니다. 음... 네; 아무 것도 가비지 수집될 수 없기 때문에 메모리 사용을 크게 부풀릴 수 있습니다. 중간 규칙 집합도 아닙니다.

@rjgotten 흠....... 객체에 다른 객체에 대한 참조가 있는 경우 GC를 방지하는 이유는 무엇입니까? 기술적으로 모든 객체는 프로토타입 체인을 통해 공개 API 노드에 대한 참조를 유지합니다. 모든 규칙 집합 인스턴스에 대한 참조를 유지하는 일부 개체가 그 반대인 경우에만 GC를 방지합니다.

잘못 이해하신 것 같습니다.

"A가 B의 보유자"인 경우 A가 B의 가비지 수집을 방지하는 B에 대한 참조를 보유하고 있음을 의미합니다. 따라서 ImportManager를 작성했을 때 규칙 세트의 보유자로 나열되었습니다. 또한 결론을 정확히 표현했습니다. ImportManager는 규칙 세트 인스턴스의 GC를 방지하는 규칙 세트 인스턴스에 대한 참조를 보유합니다.

@rjgotten 아

좋아요, 이 급진적인 아이디어는 어떻습니까?

나는 ES6 변환을 제외한 모든 것을 체리 피킹으로 분기를 만들었습니다. 이것은 간단하지 않았고 모든 작업을 핵으로 만들 것입니다. 그러나 Babelified/Typescript'd 파일이 기존 기본 JS를 능가할 수 없다면 가치가 없습니다.

나는 우리가 git 기록을 어떻게 조정하게 될지 모르겠지만 여기에 분기 -> https://github.com/less/less.js/tree/release_v3.12.0-RC1이 있습니다. 전환을 Nuking하는 것은 큰 문제이므로 이 분기가 비교할 수 있는 확실한 벤치마킹이 될 것이라고 생각합니다.

그 변화가 어떻게 거기에 들어갔는지 궁금합니다. 내가 탓할 가능성이 높거나 ES6 리팩터에 대해 뭔가가 있어서 그렇게 했습니다. 하지만 그래, 그건 확실히 할 수 있어! 조사해주셔서 감사합니다!

확실히 이상합니다. 내가 해독할 수 있었던 것으로부터 ImportManager는 ES6 변환에 의해 추가된 글루코드/폴리필을 통해 룰셋에 대한 보유자로 끝나는 것처럼 보입니다.

중간에 끝나는 솔루션이 여기에 있는지 궁금합니다. 즉, Node.js용 ES6 빌드를 유지하지만 변환된 브라우저 대상도 있습니다. ES6 변환이 추가하는 코드 명료성을 없애는 것은 엄청난 손실입니다. 😢

@rjgotten

ES6 변환이 추가하는 코드 명료성을 없애는 것은 엄청난 손실입니다.

다음과 같은 두 가지 이유로 생각보다 나쁘지 않을 수 있습니다.

1. 롤업 구성은 여전히 ​​존재하며 누군가 조사하려는 경우 커밋에서 가져올 수 있습니다.
2. 저는 한동안 TypeScript 기반의 Less 4.0에 대해 적극적으로 작업해 왔습니다. 나는 이 성능 회귀를 추적하는 것보다 그것에 시간을 할애하고 싶습니다. 기초적인 리팩터링이기 때문에 가까운 것은 아니지만 TS의 특성상 참조를 유지하고 GC를 방지하는 이러한 일회성 개체 돌연변이가 있을 가능성은 거의 없습니다. 그리고 그 코드는 따라야 할 것이 훨씬 더 명확해졌습니다 . 그래서 거기에 있습니다.

이 문제를 해결하기 위해 모든 것을 ES5로 롤백하는 것은 _비트_ 힘든 일처럼 보이지만 재작성이 진행 중이라는 점을 감안하면 이해할 만합니다. 그럼에도 불구하고 우리는 이 결정을 가지고 얼마나 오래 살아야 하는지를 고려해야 합니다. @rjgotten이 언급했듯이 우리는 많은 코드 명확성을

코드를 공유할 의향이 있는 경험이 있는 사람이 있습니까? 변경 사항이 도움이 되는지 여부를 확인할 수 있도록 실제 프로젝트를 사용하여 벤치마킹할 수 있다면 좋을 것입니다. 우리가 그것을 얻을 수 있다면 병목 현상이 있을 수 있는 곳을 좁히려고 노력하는 데 도움을 드릴 의향이 있습니다.

@matthew-dean, 참고로 Babel을 느슨한 모드에서 컴파일하여 더 깔끔한 코드를 생성했는지 확인하셨습니까?

@seanCodes 누군가가 Rollup/Typescript의 출력이 어떻게/왜 더 나빠지고 이러한 추가 메모리 효과가 있는지 조사할 시간이 있다면 핵 옵션을 선택하지 않은 것에 대해 모두

내가 가진 한 가지 추측은 일부 분해 논리에는 많은 개체 생성 상용구가 있다는 것입니다.

기본적으로 누군가가 이 문제를 소유하기 위해 자원해야 합니다.

@matthew-dean, 참고로 Babel을 느슨한 모드에서 컴파일하여 더 깔끔한 코드를 생성했는지 확인하셨습니까?

@seanCodes 이 코드는 Babel이 아닌 TypeScript를 사용하여 컴파일됩니다. 내 생각은 JSDoc 유형을 점진적으로 추가하여 유형 검사를 더 강력하게 만드는 것이지만 v4의 TS는 다시 작성하기에 충분합니다. 필요한지 잘 모르겠습니다. 따라서 누군가 Babel v. TypeScript(및 각각 다른 설정)를 실험하여 Babel이 더 성능이 좋은 코드를 생성하는지 확인할 수 있습니다. 초기에 Node.js용 비 ES5 빌드를 생성하여 발생하는 이 문제에 대해 매우 주의 하십시오 .

@seanCodes 또한 성능 차이를 확인하는 것이 여전히 어렵다는 것을 알았습니다. 성능의 차이를 확실히 증명하기 위한 PR/단계를 생성한 사람은 아무도 없습니다. 이 스레드에는 많은 일화가 있지만 재현 가능한 코드나 단계가 없으면 누군가가 이것을 조사하는 방법이 확실하지 않습니다. 이상적으로는 프로파일링 도구(Chrome 디버거 또는 기타를 통해)를 시작하여 시스템에 숫자를 출력하는 PR이 있고 여러 테스트에 대해 평균을 내고 있습니다. 따라서 이것은 지금까지 100% 재현할 수 없기 때문에 누구나 복제 단계를 제공할 수 있는 한, 부분적으로는 개인적으로 그 토끼굴로 가고 싶지 않은 이유가 있습니다. (즉, "Chrome 디버거를 사용했습니다"라는 피드백은 일련의 재현 단계가 아닙니다. 알아두면 유용하지만 누군가 조사하는 데 도움이 되지는 않습니다. 우리는 우리가 무엇을 추적하는지, 왜/어떤 결과가 나오는지 알아야 합니다. 예상되는.)

따라서 사람들이 현재 코드베이스를 사용하여 Less 성능을 향상시키려면 이 문제를 소유하는 데 여러 자원 봉사자와 한 사람이 필요할 것입니다.

개인적으로 _speed_에서와 같은 성능 차이를 많이 보지 못했지만 메모리 소비의 차이는 놀랍고 가져오기의 양과 상관 관계가 있는 것 같습니다. 내 피상적인 힙 분석도 이 문제와 관련이 있는 것으로 제안하는 것 같습니다.

그것이 맞다면, ~당신~은 차이점을 보기 위해 각각에 일부 규칙 세트가 포함된 많은 가져온 파일로 구성되어 있는 한 실행 가능한 테스트 프로젝트를 함께 준비할 수 있어야 합니다.

@rjgotten

그것이 맞다면, 각각 약간의 규칙 세트를 포함하는 많은 가져온 파일로 테스트 프로젝트를 함께 조작할 수 있어야 하며 차이점도 확인할 수 있습니다.

"당신"은 여기서 중요한 부분입니다. 😉

"당신"은 여기서 중요한 부분입니다. 😉

불행한 단어 선택. 제 말은 일반적인 의미에서 - 즉 "누구나"입니다.
더 깊이 파고들고 싶지만 현재 너무 많은 판이 회전하고 있습니다.

@rjgotten "많은 수의 가져온 파일"이 무엇인지 더 잘 알 수 있습니까? 100개의 개별 파일이 이를 수행합니까, 아니면 1000개를 말하는 것입니까?

또한 이 문제를 어떻게 처음 알게 되었습니까? 메모리 사용으로 인해 빌드가 실패했습니까? 아니면 메모리 사용을 보고 있었습니까? 아니면 기계가 느려지는 것을 눈치채셨습니까?

나는 이것을 아직 복제하려고 시도하지 않았지만 추측하고 확인하는 것에 의존할 필요가 없도록 정확히 무엇을 찾아야 하는지 배우기를 여전히 희망하고 있습니다.

100개 정도면 됩니다. 이는 내가 문제를 발견한 실제 프로젝트의 크기와 비슷합니다.

회사 CI 환경에서 실행 중인 빌드가 실패하기 시작했을 때 처음으로 알아차렸습니다. 메모리 제한이 구성된 Docker 컨테이너 내부에서 실행합니다.

@rjgotten 3.11.3에서 여전히 메모리 문제가 있습니까? 이전 릴리스에서 가져오기 내에서 AST의 모든 캐싱(참조)을 제거했으므로 가져오기가 보류 중이고 그 안에 AST 트리가 유지되고 있으면 메모리 사용량이 증가하지만 유지에서 트리를 삭제하면 그게 해결이 되나요?

@matthew-dean 예, 문제는 3.11.3에도 여전히 존재합니다.

나는 개념 증명을 만들려고 노력할 것이지만 내 접시에 많은 것이 있습니다. 시간이 좀 더 생기면 할 일 목록에 넣어두었습니다.

@matthew-dean 이전에 실패했던 비교적 큰 프로젝트에서 이것을 테스트하고 싶습니다. 내가 알아야 할 것이 있습니까? https://github.com/less/less.js/tree/release_v3.12.0-RC1 이 분기를 사용해야 합니까?

@nfq 시도해 볼 수 있지만 이 스레드의 일반적인 지혜는 해당 분기가 수행하는 ES6 변환을 폭파하지 않고 대신 문제를 적절하게 진단하기 위해 더 많은 정보를 얻는 것입니다.

덧붙여서, 나는 영구 객체를 찾으려고 컴파일하는 동안 less 객체를 검사하려고 시도했지만 아무 것도 찾지 못했습니다. 🤷‍♂️

성능 문제도 겪고 있습니다. 동일한 테스트 스위트의 경우:

| 버전 | 시간 |
| -- | -- |
| v3.9.0 | ~1.6초 |
| v3.10.0~v3.11.1 | ~3.6초 |
| v3.11.2+ | ~12초 |

여기서 논의된 3.9.0 → 3.10.0 외에도 v3.11.2 에서 상당한 성능 저하가 있는 것 같습니다. 변경 로그의 이 변경 사항은 의심스러운 것 같습니다.

3498 가져오기 관리자에서 트리 캐싱 제거(#3498)

저에게도 마찬가지입니다.

동일한 빌드에 대한 타이밍(모두 노드 10.19.0에서):

• v3.9: 29.9초
• v3.10: 76.0초
• v3.12: 89.3초

@jrnail23

그 결과를 보여줄 수 있는 repo가 ​​있습니까?

@matthew-dean https://github.com/less/less.js/issues/3434#issuecomment -672580467: https://github.com/ecomfe/dls-tooling/tree/master/packages/ less-plugin-dls (Less 플러그인을 포함하는 모노레포입니다.)

죄송합니다, @matthew-dean, 그렇지 않습니다. 그 결과는 내 고용주의 제품에서 나온 것입니다.

그 결과는 내 고용주의 제품에서 나온 것입니다.

같은 이유로 파일을 제공할 수 없습니다. 😞

@rjgotten @jrnail23 @Justineo - 궁금한데, 같은 가져오기를 다른 파일에서 여러 번 가져오는 경우가 많습니까?

제 경우 에는 @import 문 을

@matthew-dean, 일반적인 것들(예: 색상 변수, 타이포그래피 등)을 가져오는 base.less 파일이 있습니다.
우리 앱을 빠르게 검색해보면 base.less 참조(예: <strong i="8">@import</strong> (reference) "../../../less/base.less"; )가 66개의 다른 구성요소/기능별 less 파일에서 가져오고 이러한 파일 중 일부는 또한 다른 구성 요소/기능별 덜 파일(자체적으로 base.less 참조할 수 있음)을 가져옵니다.
흥미롭게도 (아마도 실수로?) 참조로 자신을 가져오는 또 다른 less 파일이 있는 것 같습니다.

@rjgotten @jrnail23 @Justineo - 궁금한데, 같은 가져오기를 다른 파일에서 여러 번 가져오는 경우가 많습니까?

저에게는 '예'입니다. 내가 처음으로 문제를 경험한 프로젝트는 다른 모든 파일에 포함된 중앙 집중식 변수 파일을 사용하는 스킨 가능한 솔루션입니다. 게다가, 우리는 예를 들어 특정 유형의 버튼, 글꼴 아이콘 등을 생산하는 믹스인 팩토리가 있는 구성 요소 기반 디자인을 사용하고 그 일부도 여러 파일로 가져옵니다.

원래; 모든 종속 항목은 종속 항목을 엄격하게 가져오도록 설정되어 있으며 Less 컴파일러에 의존하여 중복 제거 및 가져오기 순서를 올바른 순서로 지정하고 올바른 CSS 출력을 보장합니다.

@rjgotten

글을 올렸다가 지웠는데(알았다고 생각했지만 여전히 복제할 수 없었기 때문에), 어떤 프로세스를 포함하여 사람들이 보고하는 내용을 재현할 단계가 아직 없습니다.

다음과 같이 간단한 것조차도:

3.11에서 RuleSet에 대해 나열된 보유자 중 하나는 ImportManager입니다.

나는 그것에 대한 증거를 찾을 수 없지만 어떻게 당신이 그것을 결정할 수 있었는지 모르겠습니다. 나는 Chrome DevTools에 익숙하지 않아 무엇에 의해 유지되는 것과 같은 것을 어떻게 결정할 수 있는지 알 수 없으며 Google이 나를 돕지 않은 모호한 주제입니다. 예를 들어 사람들이 노드 프로세스에 연결합니까? 브라우저에서 실행하고 중단점을 설정하시겠습니까? 단계는 무엇입니까?

요컨대, 이 문제가 시작된 해에 어떤 ​​보고서도 재현할 단계가 없습니다. 나는 이 모든 일화가 의미하는 바가 있다고 확신하지만, 당신이 발견한 것을 어떻게 결정했나요? 아니면 이것을 보여 줄 설정을 생각할 수 있습니까? 이해하는 데 도움을 주고 싶지만 재현하는 방법을 모르겠습니다.

@Justineo 리포지토리에서 메모리 크기나 컴파일 시간을 결정하기 위해 어떤 단계를

@Justineo 캐시 제거(아마도 나쁜 생각일 수 있음)를 지적 https://github.com/less/less.js/tree/cache-restored

오늘의 실험/테스트에 대한 몇 가지 업데이트를 제공하기 위해:

그런트의 shell:test 번

• 3.9 - 1.8초 미만
• 3.12 미만(Babel을 ES5로 변환) -- 9.2s
• 3.12 미만(Babel을 ES6으로 변환) -- 3.1s
• 3.12 이하(TypeScript를 ES5로 변환) -- 3.2s

그래서 길고 짧은 것은 트랜스파일된 코드가 항상 느리고 우리가 다르게 생각하는 순진한 것이라고 생각합니다. 자바스크립트 세계에서 트랜스필레이션이 이제 "표준"이기 때문에 약간 놀랐습니다. 이를 뒷받침하는 다른 연구가 있습니까?

@Justineo 리포지토리에서 메모리 크기나 컴파일 시간을 결정하기 위해 어떤 단계를

npm run test 는 경과된 총 시간을 생성합니다. 그리고 다른 프로젝트에서는 3.12로 전환할 때 OOM을 경험하고 있습니다.

TypeScript 생성 코드를 보면 다음과 같은 결과를 얻습니다.

Object.defineProperty(exports, "__esModule", { value: true });
var tslib_1 = require("tslib");
var node_1 = tslib_1.__importDefault(require("./node"));
var variable_1 = tslib_1.__importDefault(require("./variable"));
var property_1 = tslib_1.__importDefault(require("./property"));
var Quoted = /** <strong i="6">@class</strong> */ (function (_super) {
    tslib_1.__extends(Quoted, _super);
    function Quoted(str, content, escaped, index, currentFileInfo) {
        var _this = _super.call(this) || this;
        _this.escaped = (escaped == null) ? true : escaped;
        _this.value = content || '';
        _this.quote = str.charAt(0);
        _this._index = index;
        _this._fileInfo = currentFileInfo;
        _this.variableRegex = /@\{([\w-]+)\}/g;
        _this.propRegex = /\$\{([\w-]+)\}/g;
        _this.allowRoot = escaped;
        return _this;
    }

대:

var Node = require('./node'),
    Variable = require('./variable'),
    Property = require('./property');

var Quoted = function (str, content, escaped, index, currentFileInfo) {
    this.escaped = (escaped == null) ? true : escaped;
    this.value = content || '';
    this.quote = str.charAt(0);
    this._index = index;
    this._fileInfo = currentFileInfo;
    this.variableRegex = /@\{([\w-]+)\}/g;
    this.propRegex = /\$\{([\w-]+)\}/g;
};

그래서 내 생각에 모든 추가 기능 정의와 호출은 시간이 지남에 따라 합산됩니까? 이것이 붉은 청어가 아닌 한, 그러나 나는 트랜스필을 제외하고 이것을 무엇으로 귀속시켜야 할지 모르겠습니다. 내가 이해하지 못하는 것은 TS가 원본에 더 가까운 코드를 생성할 수 없는 이유입니다.

업데이트:

3.9 테스트를 3.12에 있는 것과 동등하게 하려고 하면 본질적으로 1.2 대 1.3이 됩니다. 테스트가 변경되었기 때문에 이 차이에 대해 더 이상 확신할 수 없습니다. 정확히 동일한 적은 수의 파일에 대해 실행해야 합니다.

@Justineo @rjgotten 좀 더 효율적인 빌드를 만들기 위해 몇 가지 TypeScript 조정을 푸시했습니다. 해당 분기를 빌드하고 사용하시겠습니까? https://github.com/less/less.js/tree/cache-restored

@matthew-dean 👍 감사합니다! 오늘 나중에 시도해 보겠습니다.

cache-restored 분기를 테스트했는데 v.3.1.0~3.11.1과 거의 같은 속도로 v3.11.2+보다 훨씬 빠릅니다.

@저스티네오

캐시 복원 분기를 테스트했는데 v.3.1.0~3.11.1과 거의 동일한 속도로 v3.11.2+보다 훨씬 빠릅니다.

글쎄, 그것은 유망하다. @rjgotten @jrnail23 및 이 스레드의 다른 사람들로부터 피드백을 받도록 합시다. 해당 캐시 제거는 이 스레드가 게시된 후였습니다(3.11.2). 사실 그것은 메모리 오버헤드의 일부를 제거하려는 시도였지만 동일한 파일을 여러 번 가져오는 경우 상황을 더 악화시킬 수 있습니다.

따라서 간단히 말해서, 나는 여전히 원래 문제나 그 원인(코드 변환에서 발생한 어떤 것은 제외)에 대해 확신하지 못하며 이 분기에 여전히 그러한 문제가 있는지 알고 싶지만 앞서 언급했듯이 , 명확한 재현 단계가 없으므로 확실하지 않습니다.

@matthew-dean, cache-restored 분기를 사용하는 데 약간의 문제가 있습니다( npm link 가 실패하므로 로컬에서 사용하기 위해 수행해야 할 작업이 명확하지 않습니다. 나).
내가 시도할 수 있는 카나리아/시험판 버전을 게시할 수 있습니까?

@jrnail23

나는 이것이 효과가 있었다고 생각한다. Less를 제거하고 npm i [email protected]+84d40222 설치해 보세요.

@matthew-dean, 방금 그 버전을 시도했지만 여전히 나에게 나쁩니다.
새로운 웹팩 빌드(캐싱 없음)의 경우 v3.9의 경우 62.4초가 소요되지만 v3.13.1의 경우 121초가 소요됩니다.
캐시된 빌드의 경우 v3.9는 30초, v3.13.1은 83-87초가 소요됩니다.

@jrnail23 모든 노드 모듈을 제거하고 [email protected]+b2049010 설치를 시도할 수 있습니까?

3.9 미만 벤치마크:

4.0.1-alpha.0 미만:

4.0.1-alpha.2 미만:

@Justineo @rjgotten 이것도 해보 시겠어요 ?

@jrnail23 @Justineo @rjgotten

이것은 4.0 빌드이므로 코드에 다음과 같은 주요 변경 사항이 있는 경우 오류가 발생할 수 있습니다.

• 믹스인 호출에는 괄호가 필요합니다(예: .mixin; 는 허용되지 않음).
• Less의 기본 수학 모드는 이제 괄호 나누기이므로 슬래시(수학으로 의도됨)는 괄호 안에 있어야 합니다.

따라서 지금은 훨씬 더 낙관적이지만 최신 벤치마크를 기반으로 문제를 해결했지만 이 문제가 발생한 이유를 아직 파악하지 못했습니다. 성능이 다른 모든 사람에게 적용되는 경우 최종적으로 문제 범위를 좁힌 방법과 발견한 내용을 요약할 수 있습니다. 다시 말해, 문제가 _어디에서_ 발견되었지만 반드시 그 이유는 아닙니다.

https://github.com/less/less.js/issues/3434#issuecomment -672580467과 동일한 테스트 모음의 결과:

| 버전 | 시간 |
| -- | -- |
| v3.9.0 | ~1.6초 |
| v3.10.0~v3.11.1 | ~3.6초 |
| v3.11.2+ | ~12초 |
| 4.0.1-알파.2+b2049010 | ~1.6초 |

특정 테스트 제품군의 경우 성능 수준이 v3.9.0만큼 빠르게 향상되었음을 확인할 수 있습니다. Matt에게 매우 감사드립니다! 수학 모드의 중단 변경에 대해 잘 모르겠습니다. 이것을 변경하면 많은 응용 프로그램이 손상될 수 있으므로 성능 문제가 해결되더라도 v3.9.0에서 멈출 수 있습니다.

@저스티네오

수학 모드의 중단 변경에 대해 잘 모르겠습니다.

math=always 모드에서 명시적으로 컴파일하여 이전 수학 동작을 가져올 수 있습니다. 그냥 다른 기본값입니다.

문제 분석

TL;DR - 클래스 패턴을 조심하십시오

문제는 Babel과 TypeScript 모두에서 클래스를 변환하는 데 있었습니다. (즉, 둘 다 트랜스파일된 코드에서 동일한 성능 문제가 있었고 Babel은 약간 더 나빴습니다.) 이제, 몇 년 전 클래스 패턴이 도입되었을 때 저는 들었습니다. JavaScript의 상속은 기능 상속을 위한 구문 설탕입니다.

요컨대 그렇지 않습니다. _(편집: 글쎄요.... 그렇습니다. 그렇지 않습니다. 그것은 "상속"이 무엇을 의미하는지, 그리고 곧 보게 될 것처럼 정의한 방법에 따라 다릅니다.... 즉, 몇 가지 패턴이 있습니다. JavaScript의 프로토타입 체인에 "상속"을 만들고 클래스는 하나의 패턴만 나타내지만 해당 패턴은 다른 모든 패턴과 다소 다르기 때문에 특수 기능을 사용하여 이 패턴을 "모방"하기 위한 도우미 코드가 TS/Babel에 필요합니다.)_

더 적은 코드는 다음과 같습니다.

var Node = function() {
  this.foo = 'bar';
}

var Inherited = function() {
  this.value = 1;
}
Inherited.prototype = new Node();

var myNode = new Inherited();

이제 "현대" JS를 사용하여 이것을 다시 작성하고 싶다고 가정해 보겠습니다. 사실, 내가 했던 이 프로세스를 자동화할 수 있지만 어느 쪽이든 동일하게 작성했을 것입니다.

class Node {
  constructor() {
    this.foo = 'bar';
  }
}
class Inherited extends Node {
  constructor() {
    super();
    this.value = 1;
  }
}
var myNode = new Inherited();

같은 거 맞죠? 사실, 아니. 첫 번째는 { value: 1 } 속성을 가진 객체를 생성하고 프로토타입 체인에서 { foo: 'bar' } 객체를 가집니다.

그것은 모두 생성자 호출하므로 두 번째는, Inherited 및 Node 같은 구조를 가진 개체 생성한다 { value: 1, foo: 'bar' } .

당신이 액세스 할 수 있기 때문에 이제, _user_의 경우,이 정말 중요하지 않습니다 모두 value 및 foo 에서 myNode 어느 경우이다. _기능적으로_, 그들은 똑같이 행동하는 것처럼 보입니다.

여기에서 내가 순수한 추측을 입력합니다.

V8과 같은 JIT 엔진에 대한 기사에서 기억하는 바에 따르면 객체 구조는 실제로 매우 중요합니다. { value: 1 } , { value: 2 } , { value: 3 } , { value: 4 } 와 같은 구조를 생성하면 V8은 해당 구조의 내부 정적 표현을 생성합니다. 기본적으로 구조 + 데이터를 한 번 저장한 다음 데이터를 3번 더 저장합니다.

하지만 { a: 'a', value: 1 } , { b: 'b', value: 2 } , { c: 'c', value: 3 } , { d: 'd', value: 4 } 와 같이 매번 다른 속성을 추가하면 { a: 'a', value: 1 } 개의 데이터 세트가 있는 4개의 다른 구조입니다. , 동일한 원본 클래스 집합에서 생성된 경우에도 마찬가지입니다. JS 객체의 모든 돌연변이는 데이터 조회를 최적화하지 않고 함수로 변환되는 클래스 패턴은 더 고유한 돌연변이를 유발합니다(어쩌면). (솔직히 이것이 브라우저의 기본 클래스 지원에 대해 사실인지 여부는 모르겠습니다.)

AFAIK, 또한 사실은 개체에 대한 속성이 많을수록 개별 속성 조회가 더 오래 걸린다는 것입니다.

다시 말하지만 최종 사용자에게는 JS 엔진이 너무 빠르기 때문에 거의 문제가 되지 않습니다. Buuuuut는 가능한 한 빨리 많은 개체에 대한 속성/메소드를 만들고 조회하는 엔진을 유지 관리하고 있다고 말합니다. (Ding ding ding.) 갑자기 TypeScript/Babel이 개체를 "확장"하는 방식과 기본 기능 프로토타입 상속 간의 이러한 작은 차이가 매우 빠르게 추가됩니다.

이전 Less 구문과 TS로 변환된 클래스 패턴을 사용하여 Node 및 상속 기능의 기본 구현을 작성했습니다. 게이트에서 바로 상속된 노드는 25% 더 많은 메모리/리소스를 소비하며 이는 상속된 노드의 인스턴스가 생성되기 전입니다.

이제 일부 노드가 다른 노드에서 상속한다고 가정합니다. 즉, 클래스의 메모리 내 표현은 상속된 인스턴스와 마찬가지로 증가하기 시작합니다.

이번에도 추측입니다

나는 이 모든 것을 한 알의 소금으로 받아들이는 것을 강조해야 한다. 왜냐하면 나는 수업으로의 전환이 성능에 있어서 이렇게 비참한 것을 들어본 적이 없기 때문이다. 내가 _생각하는_ 일은 Less가 JIT를 심각하게 비최적화하고 있는 개체/인스턴스 조회의 특별한 조합이 있다는 것입니다. _(일부 자바스크립트 엔진 전문가가 이 경우에 왜 트랜스파일된 클래스가 네이티브 JS 상속 메서드보다 훨씬 더 나쁜 성능을 발휘하는지 알고 있다면 알고 싶습니다.)_ 두 메서드를 모두 사용하여 수천 개의 상속된 객체를 생성하는 성능 측정을 만들려고 했습니다. 일관된 성능 차이를 볼 수 없었습니다.

따라서 "자바스크립트의 클래스는 나쁘다"라는 말을 하기 전에 트랜스파일된 클래스와 네이티브 JS의 차이 와 결합하여 이러한 성능 저하를 초래한 Less 코드베이스의 다른 정말 불행한 패턴이 될 수 있습니다.

내가 마침내 그것을 알아 낸 방법

솔직히 저는 수업 패턴을 의심한 적이 없습니다. 원래 ES5 코드가 역-Babelified 코드보다 빠르게 실행된다는 것을 알고 있었지만 화살표 기능이나 어딘가에 구문을 퍼뜨리는 부분이 의심스러웠습니다. 난 아직도 실행하기로 결정 일일 있도록 최신의 ES5 지점했다 lebab 다시를, 단지 이러한 변환 사용 : let,class,commonjs,template . 그제서야 성능 문제가 있음을 다시 발견했습니다. 나는 그것이 문자열 템플릿이나 let-to-var가 아니라는 것을 알고 있었습니다. 나는 아마도 require-to-imports가 뭔가를 했다고 생각해서 한동안 그것을 가지고 놀았습니다. 그것은 수업을 떠났다. 그래서 직감적으로 모든 확장된 클래스를 다시 기능적 상속으로 다시 작성했습니다. Bam, 성능이 돌아왔습니다.

경고의 이야기

그래서! 교훈을 얻었습니다. 프로젝트가 오래된 ES5 코드에 있고 "현대적인" Babel-ified 또는 TypeScripted 장점을 갈망하고 있다면 무엇을 트랜스파일하든 작성하지 않았음을 기억하십시오.

나는 여전히 클래스를 좀 더 유지 관리하기 쉬운 패턴으로 더 "클래스와 같은" 것으로 다시 작성할 수 있었지만 Less 노드의 원래 기능 상속 패턴을 어느 정도 유지했으며 프로젝트에 강력한 메모를 남길 것입니다. 다시는 이런 짓을 하지 않는 미래의 관리자.

Math=always 모드에서 명시적으로 컴파일하여 이전 수학 동작을 얻을 수 있습니다. 그냥 다른 기본값입니다.

나는 이것을 알고 있다. 여러 팀에 걸쳐 많은 Less 코드베이스가 있으므로 기본 컴파일 옵션을 변경하더라도 통신 비용이 증가합니다. 이점이 깨질 가치가 있는지 확실하지 않습니다.

상세한 분해 감사합니다!

컴파일된 출력에서 Object.assign 의 사용법을 보았습니다. 즉, 이제 폴리필이 필요하지 않는 한 기본 ES class 구문을 지원하는 브라우저에서만 작동합니다. 따라서 이전 환경(예: IE11, Node 4 등)에 대한 지원을 중단하려는 경우 ES5로 변환하지 않고 기본 구문을 사용할 수 있습니까?

동시에 성능 저하 수정과 주요 변경 사항을 분리할 수 있다면 더 좋을 것 같습니다. 즉, v3에 성능 수정 사항을 적용하고 v4에만 주요 변경 사항을 포함하는 것입니다.

@matthew-dean
ES 수업이 범인이라는 사실이 정말 무섭습니다.
상세한 분석 감사합니다.

표시로 이동: _상속보다 구성_ 😛

참고로; 더 깔끔한 원형 상속 체인을 원하면 실제로 예제와 약간 다르게 수행해야 합니다.
Object.create 과 같이 사용하는 경우:

var Node = function() {
  this.foo = 'bar';
}
Node.prototype = Object.create();
Node.prototype.constructor = Node;

var Inherited = function() {
  Node.prototype.constructor.call( this );
  this.value = 1;
}
Inherited.prototype = Object.create( Node.prototype );
Inherited.prototype.constructor = Inherited;

var myNode = new Inherited();

그런 다음 동일한 모양을 공유하는 인스턴스 자체에 속성을 병합합니다. 프로토타입은 모양을 공유합니다. _및_ 각 속성 액세스에 대해 프로토타입 체인을 크롤링할 필요가 없습니다. 😉

@저스티네오

컴파일된 출력에서 ​​Object.assign의 사용법을 보았습니다. 즉, 이제 폴리필이 필요하지 않는 한 기본 ES 클래스 구문을 지원하는 브라우저에서만 작동합니다. 따라서 이전 환경(예: IE11, Node 4 등)에 대한 지원을 중단하려는 경우 ES5로 변환하지 않고 기본 구문을 사용할 수 있습니까?

나는 그것이 옳다고 생각하지 않습니다. 즉 Object.assign이 클래스 구현 직전에 착륙했지만 귀하의 요점은 채택되었습니다. 나는 [Something].prototype.property 계속해서 쓰지 않기를 바랐습니다./

기술적으로 모든 것이 여전히 트랜스파일 중이므로 잘 모르겠습니다. 원래의 목표는 유지보수가 용이하고 읽기 쉬운 코드 기반이었습니다. 어떤 환경에서 Object.assign polyfill이 필요하다면 그렇게 하세요. Less가 지원하지 않는 버전일 것입니다.

동시에 성능 저하 수정과 주요 변경 사항을 분리할 수 있다면 더 좋을 것 같습니다. 즉, v3에 성능 수정 사항을 적용하고 v4에만 주요 변경 사항을 포함하는 것입니다.

나는 그것에 대해 생각하고 있으며, 그것이 또한 정당한 지적이라고 생각합니다. 나는 단지 Less의 3가지 주요 버전을 구축/유지하는 것이 폭발하지 않도록 하려고 합니다.

@rjgotten AFAIK 그것이 바로 클래스 패턴이 정의한 대로 수행되어야 하는 작업입니다. 내가 결정적인 차이를 보지 않는 한. 그래서 🤷‍♂️ . 나는 그것이 실적이 우수한 다시 이하의 노드 상속 패턴을 변경하려고하지 않을거야 (다른 I이 제거 할 수 있습니다보다 Object.assign @Justineo 제안으로 전화를.)

@Justineo @rjgotten 이것을 시도할 수 있습니까: [email protected]+b1390a54

방금 시도했습니다.

| 버전 | 시간 |
| -- | -- |
| v3.9.0 | ~1.6초 |
| v3.10.0~v3.11.1 | ~3.6초 |
| v3.11.2+ | ~12초 |
| 4.0.1-알파.2+b2049010 | ~1.6초 |
| 3.13.0-alpha.10+b1390a54 | ~4.7초 |

추신. Node.js v12.13.1로 테스트했습니다.

나는.... 뭐.

별도의 벤치마크를 설정할 시간이 없었습니다.
그러나 통합 테스트 관점에서 볼 때 실제 수치는 다음과 같습니다. Less를 사용하는 프로덕션급 Webpack 프로젝트의 누적 결과입니다.

버전 | 시간 | 피크 메모리
:------------------------|--------:|------------:
3.9 | 35376ms | 950MB
3.11.3 | 37878ms | 920MB
3.13.0-alpha.10+b1390a54 | 34801ms | 740MB
3.13.1-알파.1+84d40222 | 37367ms | 990MB
4.0.1-알파.2+b2049010 | 35857ms | 770MB

저에게 3.13.0은 _best_ 결과를 제공합니다... 🙈

3.11.3은 이전에 3.11.1 버전에서 보았던 런어웨이 메모리 사용이 없는 것 같습니다.
그러나 4.0.1 및 3.13.0 베타가 여전히 더 좋습니다.

캐시를 복원한 3.13.1은 실제 컴파일 시간을 개선하는 데 도움이 되지 않고 메모리 사용을 부풀릴 뿐입니다.

@rjgotten 예, 문제는 이 스레드에서 사람들이 서로 다른 것을 측정하고 있으며 지금까지 모든 사람이 본질적으로 복제할 수 없는 개인 데이터를 가지고 있다는 것입니다(Less 벤치마킹에 제출하거나 이를 PR로 변환하지 않고). Less에는 리포지토리의 다른 클론에 대해 사용할 수 있는 벤치마크 테스트가 있어 구문 분석/평가 시간의 차이를 직접 확인할 수 있지만 캐싱이 (현재) 적용되지 않는 경우.

다음은 트리에 대한 상속 변경 사항과 구문 분석 트리 캐시가 복원된 게시된 빌드입니다. [email protected]+e8d05c61

테스트 케이스

https://github.com/ecomfe/dls-tooling/tree/master/packages/less-plugin-dls

결과

| 버전 | 시간 |
| -- | -- |
| v3.9.0 | ~1.6초 |
| v3.10.0~v3.11.1 | ~3.6초 |
| v3.11.2+ | ~12초 |
| 4.0.1-알파.2| ~1.6초 |
| 3.13.0-알파.10| ~4.7초 |
| 3.13.0-알파.12 | ~1.6초 |

Node.js 버전

v12.13.1

나에게 이 버전은 완벽하게 작동하는 것 같다. 동료들에게 시도해 보고 확인하도록 요청하겠습니다.

나를 위해 alpha.10 보다 약간 더 나쁘게 작동하지만 차이가 있을 수도 있습니다.

버전 | 시간 | 피크 메모리
:------------------------|--------:|------------:
3.9 | 35376ms | 950MB
3.11.3 | 37878ms | 920MB
3.13.0-alpha.10+b1390a54 | 34801ms | 740MB
3.13.0-alpha.12+e8d05c61 | 36263ms | 760MB
3.13.1-알파.1+84d40222 | 37367ms | 990MB
4.0.1-알파.2+b2049010 | 35857ms | 770MB

@matthew-dean, 내 코드가 아직 4.0.1-alpha.2+b2049010 변경 사항과 호환되지 않는 것 같습니다. 문제를 해결할 수 있는지 확인하고 시도해 보겠습니다.

@rjgotten 네, 그 차이는 귀하의 테스트 사례에서 사소한 것 같습니다.

이것의 결과는 3.x와 4.0 릴리스를 모두 준비할 수 있다는 것입니다. 이 문제가 해결되지 않은 상태에서 4.0을 푸시하고 싶지 않았습니다. 고맙게도 그렇게 된 것 같습니다.

내가 할 또 다른 항목은 특정 벤치마크 임계값 아래로 떨어지면 덜 실패하는 CI 파이프라인에 넣는 것입니다.

@jrnail23 4.0 알파를 실행하도록 수정할 수 있으면 [email protected]+e8d05c61 시도할 수 있습니까?

@matthew-dean, 내 빌드에 대해 다음을 얻습니다.

• v3.9: 98초
• v3.10.3: 161초
• v3.13.0-alpha.12: 93-96초

그래서 당신은 당신이 원하는 곳으로 돌아간 것처럼 보입니다! 잘 하셨어요!

잘 하셨어요!

네, 두 번째로 가겠습니다. 제삼; 그리고 네 번째.
이것은 정말 _많은_ 노력을 들여 제거하는 불쾌하고 불쾌한 성능 회귀였습니다.

작업 _매우 잘_ 완료했습니다.

좋아 팀! 저는 3.x 빌드를 게시할 예정이며 나중에 언젠가는 아마도 다음 주에 4.0을 게시할 것입니다. 이제 둘 다 성능 수정 사항이 있어야 합니다. 디버깅에 도움을 주신 모든 분들께 감사드립니다!

그건 그렇고, 저는 현재 Less.js 코드베이스를 TypeScript로 변환하는 과정에 있으며, 그 기회를 이용해 약간의 성능 튜닝/리팩토링을 할 계획입니다. 관심 있는 사람이 있으면 기꺼이 도와드리겠습니다! https://github.com/matthew-dean/less.js/compare/master...matthew-dean:next

추가 눈을 선호하는 특정 부분이 있습니까? 홍보가 너무 커서 어디서부터 시작해야 할지 모르겠어

@kevinramharak 공정한 질문입니다. 솔직히 TypeScript로 변환하는 과정에서 예상치 못한 난관에 부딪혀(해결하기 어려워진 오류), 지금은 아예 다시 생각하고 있습니다. Less는 있는 그대로 잘 실행되고 있으며, 새로운 언어 기능에 대한 아이디어를 새로운 사전 버전으로 옮기기로 결정했기 때문에 (리팩토링/새로운 언어 기능을 더 쉽게 추가하기 위해) 변환하고 싶었던 많은 이유가 이제 무의미합니다. 처리 언어. 자기 홍보를 하고 싶지 않으니 자세한 내용을 원하시면 트위터나 지터로 DM주세요.