Ember.js: 버전 2.X와 3.X 간의 성능 손실

내 컴퓨터에서 Chrome 81을 몇 번 실행 한 후 다음을 얻었습니다.

2.18 최적 시간 : 283ms
3.18 최적 시간 : 471ms

DevTools가 닫힌 상태에서 실행되었습니다.

그런 다음 3.18 twiddle을 Ember Octane으로 변환했습니다.

• 구성 요소 및 컨트롤러에 네이티브 클래스 사용.
• @tracked 사용하고 @computed 사용하지 않음.
• t-r 구성 요소를 백업 클래스가 필요하지 않았기 때문에 템플릿 전용 구성 요소로 변환합니다.
• 구성 요소를 호출 할 때 꺾쇠 괄호 구문을 사용합니다.
• 템플릿에서 적절한 경우 명명 된 인수 및 this. 사용.

그 후 3.18.1에서 얻은 최고의 시간은 276ms 였으므로 2.18 수치에 따라 의미있는 개선이 이루어졌습니다.

이러한 성능 테스트는 특별히 과학적이지 않았으며 성능 측면에서 어떤 변경이 가장 중요한지 조사하지 않았습니다.

트위들에서 프로파일 링하는 것은 오류가 발생하기 쉽습니다. 프로파일 링을 위해 일반 ember-cli 앱 저장소 (두 버전 각각에 대한 분기 사용)로 이식 할 수 있습니까?

@rwjblue 일반 ember-cli 앱에서 동일한 결과를 얻고 있습니다. 여기서 테스트 할 수 있습니다

@ richard-viney 고려해야 할 개선 사항이있을 수 있지만 문제는 두 버전 모두에서 사용되지 않는 코드가 사용되지 않고 성능 손실이 발생하는 것이 용납 할 수없는 것처럼 보인다는 것입니다.

• 템플릿 전용 구성 요소를 사용하면 성능이 향상 될 수 있지만 tr은 일부 내부 스타일을 계산하기 위해 가장 확실히 백업 클래스가 필요합니다. 문제를 설명하기 위해 예제가 단순화되었습니다.
• 모든 리팩토링을 통해 2.18에 비해 2 % (283ms-> 276ms) 성능 향상을 얻을 수 있습니다. 3.X로 업그레이드하는 기존 2.18 앱을 고려하십시오. 2 % 향상을 얻기 위해 모든 구성 요소를 리팩토링하는 것은 확실히 불가능합니다.

@barisnisanci 동의합니다. 업그레이드 할 때 상당한 성능 저하를 방지하기 위해 이러한 종류의 리팩토링이 필요하다고 제안하는 것은 아닙니다. 문제를 분리하고 필요한 경우 해결하는 데 도움이 될 수 있으므로 최신 규칙을 사용하여 영향이 있는지 확인하는 실험이었습니다.

중간에있는 LTS 버전, 즉 3.4, 3.8, 3.12 및 3.16을 테스트하여 성능 회귀를 도입 한 Ember 릴리스를 아는 것은 흥미로울 것입니다.

@barisnisanci Ember Twiddle 및 ember serve 는 기본적으로 개발 모드에서 실행됩니다. 개발 중에 성능을 심각하게 저하시킬 수있는 많은 추가 도구가 활성화됩니다. 개발자 인체 공학에 영향을 미칠만큼 나쁘지 않는 한 일반적으로이를 회귀 또는 문제로 간주하지 않습니다. 따라서 먼저 프로덕션 모드에서 두 버전을 모두 실행하고 있는지 다시 확인합니다.

귀하의 예제를 다운로드하고 프로덕션 모드에서 2.8과 3.18을 나란히 제공했습니다. 내가 찾은 것은 평균적으로 두 도우미 작업 사이의 타이밍이 2.8에서보다 3.18에서 더 크게 보인다는 것입니다. 많은 컨트롤없이 작업용 랩톱에서 몇 가지 샘플을 채취 한 것이므로 확실히 말하기는 어렵지만 눈을 떼면 약간의 변화가있을 수 있습니다.

그러나 다른 더 의미있는 측정 항목을 살펴보면 변화가 보이지 않습니다. 특히 콘텐츠를 렌더링하는 전체 시간을 살펴보면 일반적으로 거의 동일하게 보입니다. 예를 들어 Time to First Paint는 거의 같습니다.

많은 장소에 많은 작업이 분산되어 있으며 변경 사항을 적용 할 때 작업이 이동하지만 _overall_ 메트릭에 영향을주지 않는다는 점을 명심하는 것이 중요합니다. 이것이 TracerBench 를 사용하여 성능 변화를 확인하는 이유입니다. 렌더의 전체 단계를 고려하고 헬퍼 실행 사이의 타이밍과 같이 _micro_ 수준이 아닌 _macro_ 수준에서 모든 변경 사항을 고려하도록 설계 되었기 때문입니다.

이러한 결과를 확인하고 일반적으로 미끄러지지 않았는지 확인하기 위해 (일반적으로 잠재적 인 회귀가 예상되는 작은 변경에 사용) TracerBench 테스트를 더 긴 기간에 걸쳐 곧 시도해야합니다. 또한 추세선을 볼 수 있도록 정기적으로 실행되도록해야합니다.

@pzuraq 방금 저장소 를 rowsCount:300 했고 columnsCount:20 차이가 더 눈에 띄게되었습니다. 둘 다 --environment production

• 3.18 첫 번째 페인트 : 3489ms
  
• 2.18 첫 번째 페인트 : 2814ms
  

또한 JS Heap은 3.18에서 출시되지 않았지만 GC에서는 운이 좋지 않을 수 있습니다.

수를 늘리는 대신 스타일 바인딩, 서비스 주입, 구성 요소에 대한 더 무거운 계산을 추가 할 수 있지만 근본적인 문제를 가릴 수 있습니다.

당신이 언급했듯이 전반적인 메트릭스가 사소한 변경보다 훨씬 중요합니다. 그러나 사소한 차이로 인해 우리의 경우 성능이 크게 저하됩니다. 3.18로 업그레이드 한 후 상용 애플리케이션의 초기 렌더링 시간이 15 초에서 20 초로 증가했습니다. 약간의 밀리 초 변화보다는 백분율로 회귀를 고려할 수 있기를 바랍니다.

우리 회사는이 문제로 고통 받고 있습니다. 엠버 버전을 2.18에서 3.16으로 업데이트했습니다. 렌더링 시간이 '50'% 이상이되었습니다. 복잡한 구조를 사용할 때 약간의 밀리 초 변경보다 렌더링 시간 간의 차이가 더 분명해졌습니다. 이 문제에 대한 업데이트가 있습니까? 렌더링 시간이 % 50 증가한 벤치 마크가 있습니다. 당분간 2.18을 유지하기로 결정했습니다. 주요 리팩터링이 필요한 경우 프레임 워크 전환을 고려할 수 있습니다.

@ Caglayan06 프로덕션 플래그로 실행 중인지 확인해 주시겠습니까? 숫자가 사과와 사과인지 확인하고 싶습니다!

@ Caglayan06- 이것이 하나의 것 같지 않습니다. @barisnisanci가 제공 한 복제는 응용 프로그램 프로필에 표시된 것과 일치하지 않을 수 있습니다. 앱에서 일반적인 문제의 재현을 제공 할 수 있습니까 (또는 위에서 @barisnisanci 의 예제 저장소가 사용 시나리오 / 프로필 출력을 나타내는 지 확인)?

이 스레드에서 @barisnisanci 의 최근 게시물에 대한 의견이 있습니까?
2.18을 3.16으로 업그레이드 한 후에도 비슷한 성능 문제가 발생했습니다. 성능이 40 % 저하되었습니다. 우리는 3.12로 다운 그레이드했지만 손실의 20 % 만 절약 할 수 있었지만 여전히 2.18만큼 좋지는 않았습니다. 앞서 언급 한 방식으로 리팩토링하는 것은 프레임 워크를 전환하는 것만 큼 많은 시간이 걸립니다. 이 문제에 대한 조치를 기대해야합니까?

최근에 3.16.8 년 11 월로 업그레이드했는데 성능 테스트 케이스가 없으며 지금 당장 명백한 성능 문제를 찾지 못했습니다.
하지만 빨리 성능 문제를 해결하고 해결하기를 기대합니다.
>

PS : ie11에서 사용되는 더 많은 메모리와 CPU. 때로는 ie11 충돌이 발생합니다.

@ Caglayan06- 이것이 하나의 것 같지 않습니다. @barisnisanci가 제공 한 복제는 응용 프로그램 프로필에 표시된 것과 일치하지 않을 수 있습니다. 앱에서 일반적인 문제의 재현을 제공 할 수 있습니까 (또는 위에서 @barisnisanci 의 예제 저장소가 사용 시나리오 / 프로필 출력을 나타내는 지 확인)?

@rwjblue @barisnisanci 의 예제는 @barisnisanci가 말하는 방식과 동일하게 작동합니다.

@ Caglayan06 프로덕션 플래그로 실행 중인지 확인해 주시겠습니까? 숫자가 사과와 사과인지 확인하고 싶습니다!

@scottmessinger 예, 우리는 프로덕션 플래그로 실행 중입니다. 결과는 @barisnisanci '결과와 유사합니다.

코드 구조를 개선했습니다. 성능이 향상되었지만 여전히 ember 2.18 버전만큼 빠르지는 않습니다. 2.18에서 변경하면 최상의 결과를 얻었습니다.

3.16 코드 구문과 새로운 기능을 변경하기 위해 코드 시스템을 점검 할 수 없습니다. 우리 프로젝트가 거대하기 때문에 이것은 우리에게 너무 비쌉니다. 아마도 모든 프로젝트를 리팩토링하는 것은 프레임 워크를 변경하는 것보다 더 많은 비용이 듭니다. 이 문제에 대해 어떤 조치를 취합니까?

이 문제에 대해 어떤 조치를 취합니까?

네, 물론입니다! 프로파일 링을하고 무슨 일이 일어나고 있는지 파악할 시간 만 있으면됩니다. 그러나 그것은 당신이 파는 것 외에는 누구를 기다릴 필요가 없습니다.

@rwjblue @barisnisanci 의 예제는 @barisnisanci가 말하는 방식과 동일하게 작동합니다.

@ Caglayan06- 흠, 그게 내가 요청한 것이 아닙니다. 나는 @ barisnisanci의 예를 들어 작품, 나는 / 당신이 그것을 프로파일 /를 검토하도록 요청 응용 프로그램에 성능 특성을 비교하여 볼 수있어 알고 경우 _way_ 그 예 작업 (느립니다) 응용 프로그램을 일치합니다.

@ Caglayan06- 흠, 그게 내가 요청한 것이 아닙니다. 나는 @ barisnisanci의 예를 들어 작품, 나는 / 당신이 그것을 프로파일 /를 검토하도록 요청 응용 프로그램에 성능 특성을 비교하여 볼 수있어 알고 경우 _way_ 그 예 작업 (느립니다) 응용 프로그램을 일치합니다.

@rwjblue 나는 @barisnisanci 의 저장소 를 우리 응용 프로그램에 통합
그러나 여전히 2.18 버전만큼 빠르지는 않습니다.

몇 가지 예에 대한 응용 프로그램에서 :

그 결과 :
심지어 우리는 코드 구조, 총 평균 렌더링 시간을 개선했습니다.
2.18 렌더링 시간 : 1x 초
3.16 렌더링 시간 : 1.6x 초
3.12 렌더링 시간 : 1.4x 초

3.20에는 VM 업그레이드가 있으므로 여기에 도움이 될지 궁금합니다.

@NullVoxPopuli 는 3.20.0-beta.2 FP에서 운이 없었습니다 : 3.4 초 (3.18과 동일)

3.12는 더 나은 결과를 보여주기 때문에 자동 추적으로 문제가 발생할 수 있다고 생각합니다. 또한 # 18225는 @ Caglayan06 의

흠. 이전 버전과의 호환성이 얼마나 많은지 궁금합니다.

몇 가지 일반적인 질문 :

• 비동기 관찰자 선택적 기능 플래그의 값은 무엇입니까?
• 문제의 앱이 QP를 사용하나요?
• 부정적인 속도가 모든 경로에 영향을 줍니까? 아니면 일부에만 영향을 줍니까?

몇 가지 일반적인 질문 :

• 비동기 관찰자 선택적 기능 플래그의 값은 무엇입니까?
• 문제의 앱이 QP를 사용하나요?
• 부정적인 속도가 모든 경로에 영향을 줍니까? 아니면 일부에만 영향을 줍니까?

뿡뿡

1. 비동기 관찰자 플래그를 사용하지 않음 3.12에서 기본값이 false라고 생각합니다. 3.16에서 둘 다 테스트해도 큰 차이가 없습니다.
2. 주요 노선에서 널리 사용되는 QP. 그러나 아무것도 없이도 성능 저하가 관찰되었습니다.
3. 모든 경로가 영향을받습니다

또한 예제 저장소 는 위의 항목을 사용하지 않지만 3.X에서는 여전히 느립니다. 각 부 버전에서 렌더링 시간이 점진적으로 증가했을 수 있으므로 정확한 문제를 파악할 수 없습니다.

Tracerbench는 2.18에서 3.18이이 시나리오에서 ~ 17 % 회귀하지만, 희미한 구성 요소로의 변환이 완료되면 ~ 18 %까지 회귀하는 대신 향상된다는 것을 보여줍니다.

2.18 ~ 3.18 기타 변경 사항 없음
2.18 to 3.18 + Octane + Glimmer 구성 요소

나는 이것에 대해 자동화 된 러너를 추가 한 곳에서 이것에 대한 포크를 가지고 있으며, 버전 / 커밋별로 빠르게 좁혀서 회귀가 발생한 위치를 찾을 수 있도록 러너를 개선하기 위해 노력하고 있습니다. https://github.com/runspired/version-performance/runs/801596557

테스트를 설정해 주신 @runspired 에게

컨텍스트를 위해 @krisselden 은 전체적인 방식으로 성능을 테스트하기위한 도구로 데코레이터 구현 및 자동 추적 / 개정 추적 과 같은 내부적으로 주요 리팩터링에 사용하고 있습니다. LinkedIn에서는 Ember를 업그레이드하기 전에 응용 프로그램을 테스트하는 데 사용하며 이러한 수준의 회귀를 보지 못했습니다.

그러나 분명히 우리가 놓친 것일 수 있습니다. 결국 우리는 특정 사용 사례와 동작이있는 특정 앱을 테스트하고 있습니다. 이것은 우리의 테스트 케이스 앱이 @barisnisanci 의 복제와 같이 회귀 된 기능을 사용하지 않았기 때문에 우리가 포착하지 못한 문제 일 수 있습니다. 또한 해당 복제 문제를 수정하더라도 다른 문제를 해결하지 못할 수도 있으므로 회귀가 발생하는 경우 사용 사례에 대한 복제를 확실히 감사하겠습니다. TracerBench 설정을 사용하기 더 쉽게 만들기 위해 로컬에서 테스트하고 @runspired 와 같은 재현을 제출할 수 있도록

우리는 정확한 문제가 무엇인지 파악하고 해결책을 찾기 위해 파고들 것입니다. 가장 중요한 것은 Octane으로 속도가 빨라지는 경우에도이 수준의 회귀는 _any_ API에서 허용 되지 않는다는 것입니다. 사용자가 점진적으로 업그레이드하고 전환 할 수 없다면 우리 모두가 함께 산을 오르는 것은 아닙니다.

더 많은 업데이트를 기대해주세요. 파악하는대로 알려 드리겠습니다!

그의 사악한 멋진 https://github.com/TracerBench/tracerbench-compare-action에 대해 @runspired 에게 많은 감사를

이것에 대한 빠른 업데이트를 제공하고 싶었습니다.

우리는 일반적인 테스트 응용 프로그램 중 하나 인 emberobserver.com으로 @runspired가 설정 한 것과 유사한 TracerBench 테스트를 실행하여 개구리 비등 이 발생했는지 확인했습니다 (예 : 버전마다 중요하지 않은 작은 성능 변화). 버전이지만 큰 변화로 요약 됨). 해당 테스트의 결과는 다음과 같습니다.

ember-observer-2.18-3.18.pdf

이 결과에서 상당히 명확한 두 가지 점프가 있음을 알 수 있습니다.

1. Ember 3.0 ~ Ember 3.1
2. Ember 3.16 ~ Ember 3.17

3.17의 회귀는 Glimmer VM 업그레이드로 인한 것이며, 현재 상당히 최근이고 곧 LTS주기에서 업데이트되는 애플리케이션에 영향을 미칠 가능성이 있기 때문에이를 줄이는 데 초점을 맞추고 있습니다.

3.1의 ​​회귀는 실제로 당시 핵심 팀과의 논의를 통해 알려졌습니다. 부분적으로는 네이티브 getter를 활성화하고 Object.defineProperty 사용하여 발생했습니다. 프레임 워크가 새로운 브라우저 기능으로 발전 할 수 있도록 허용하는 회귀 분석으로 간주되었습니다.

일반적으로이 문제의 시작 부분에 제기 된 {{each}} 시나리오는 emberobserver.com보다 더 많이 그리고 다른 방식으로 회귀 한 것으로 보입니다. 3.17 회귀를 파헤친 후에는 {{each}} 최적화에 집중하여 일반적으로 개선 할 수있는 사항을 확인합니다.

양해 해 주셔서 감사합니다!

이 문제에 대한 업데이트를받을 수 있습니까? 두 달 정도 됐어요.

예! 긴 두 달이 지났고, 우리는이 문제에 대해 열심히 노력하고 있으며 Glimmer VM에서 리팩터링을 계속해 왔으며,이 문제를 잘 해결했습니다.

앞서 언급했듯이 우리는 두 가지 개별 수정 세트에 중점을 두었습니다.

1. 다음 LTS로 업그레이드하려는 사람들을 위해 3.20 LTS 릴리스에 포함되는 낮은 위험 리팩터링
2. 장기적으로 성능을 향상시키기 위해 마스터에 착륙하는 대규모 리팩터링

첫 번째 수정 세트를 위해, 우리는 가장 많은 영향을받은 코드 였기 때문에 상당한 양의 클래식 Ember 코드를 리팩토링했습니다. LinkedIn의 내부 애플리케이션 테스트를 기반으로 이러한 방식으로 전체 성능 손실을 3.16-3.20에서 통계적으로 미미한 양으로 줄일 수있었습니다. 안타깝게도 Ember Observer에 대한 테스트를 실행할 기회가 없었지만 일반적으로 서로 밀접하게 추적하므로 비슷한 결과가 될 것이라고 생각합니다.

두 번째 수정 세트의 경우 다음을 포함하여 많은 수정 사항이 매우 크기 때문에 비교적 최근에 수정했습니다.

• VM을 내부적으로 완전히 자동 추적되도록 업데이트하여 초과 태그 제거
• 복잡도가 많은 여러 구현이 아닌 단일 모노 모픽 참조 클래스를 사용하도록 VM 리팩터링
• 사용하지 않는 AoT 컴파일 모드 제거

결과는 꽤 훌륭합니다!

results.pdf

이것은 Ember의 현재 마스터를 Ember 2.18과 @barisnisanci의 위 복제품과 비교합니다. 이제 앞에서 언급했듯이 이것은 매우 구체적인 사용 사례에 대한 벤치 마크이며 지나치게 간단합니다. 실제 앱 벤치 마크에서 이처럼 극적인 개선이 보이지는 _ 않았으며 _ 전반적으로 훨씬 더 겸손했습니다. 바라건대 이것은 @barisnisanci 및 다른 응용 프로그램의 응용 프로그램에 도움이 될 것이며 우리는 그들로부터

ember의 마스터 분기로 위의 repo를 테스트했습니다. Still First Paint : (3035.7ms)가 2.18 (2752.3ms)보다 크게 보입니다.

또한 다른 엠버 버전으로 프로덕션에서 테스트되었습니다. 마스터 브랜치는 앱에서 3.12보다 % 25 ~ % 40 느립니다. 아래 결과로 우리는 주요 리팩토링 없이는 엠버를 업그레이드 할 수 없습니다.

@barisnisanci 죄송합니다. 이 스레드에서 앞서 언급했듯이 A. 문제를 확인하고 B. 개선 및 전체적으로 더 나은 솔루션을 위해 반복 할 수 있도록 이러한 결과를 통계적으로 건전한 방식으로 재현해야합니다. 이러한 벤치 마크를 직접 실행할 수 있도록 TracerBench를 애플리케이션에 추가하거나 master 에서 문제를 보여주는 다른 복제를 만드는 것이 좋습니다.