UPDATE@2016-01-26

MagJS의 성능을 재검증한 결과 아직 본격적으로 투입할 수 없다는 결과가 나왔다.

검증:MagJS의 실제 드로잉 성능

개시하다

작년 연말에 나는 리액트의 공연에 관한 재미있는 보도를 발견했다.

React + Performance = ? - Aerotwist

구글의 크롬 개발자 관계팀에서는 퍼포먼스 튜닝 상담을 생업으로 삼은 사람들이 리액트"DOM이 느려요".의 주장에 화를 내며 실제 그런지를 검증했다.
그 결과 DOM이 늦지 않았다는 것이 증명되었다(어떤 의미에서 믿을 만한 테스트도 있었고, 물론 그렇게 말해도 당연하다). 또한 리액트에 관한기본 빠른 주장은 데스크톱 버전의 크롬에서 간신히 분투하고 있지만 넥서스 5에는 상당히 불안한 요소가 남았다.상세한 상황은 원 보도를 보십시오.
지난해 7월 쓴 이 기사는 리액트 팬데믹(세계적 대유행) 내용과 무관하며, 큐타는 지금까지 아무도 보도한 적이 없다.
그러면 저도 초역을 쓰고 싶지만, 원래 보도가 쓴 지 반년이 지났기 때문에 상황 변화의 가능성을 부정할 수 없습니다.그래서 저는 MagJS 시험을 더해서 보충시험을 보기로 했습니다.
코드는 원시 포크여기에 놓다에서 나온 것이기 때문에 더 시도하고 싶은 사람은 꼭 시도해 보세요.

테스트 내용

리액트의'자바스크립트는 빠르고 DOM은 느리다'는 주장이 사실인지 검증하기 위해 무한 리스트에서 성능 변화를 살핀다.버튼을 클릭할 때마다 Flickr에서 100개의 그림을 가져와 페이지 끝에 추가합니다.
물론 이미지를 얻는 시간은 네트워크 상황에 큰 영향을 받기 때문에 측정 시간에서 제외된다.순수하게 그림의 완성에서 DOM의 업데이트가 완성될 때까지 시간은 측정의 대상이다.DOM 업데이트가 완료되면 다음 RequestAnimation Frame을 호출하기 전에 시간을 대략적으로 측정합니다.
또 오리지널 중에서는 1천200장을 테스트했고, 이번에는 추이를 더 살펴보기 위해 1천500장을 테스트했다.
원래 JS 및 React의 테스트 코드는 원래 상태로 유지됩니다.그러나 React 호스트는 집필할 때의 최신 버전 v0입니다.14.6 업데이트된 것도 테스트했다.반년 동안 리액트의 성능이 개선될 가능성이 있다는 점을 고려했다.
환경은 iMac Late 2009/OS X El Capitan입니다.지금 보니까 좀 낡았어.크롬 버전은 47.0256.106(64-bit)으로 현재 최신 버전이다.오리지널 테스트도 넥서스 5에서 테스트했으나 이번에는 하지 않는다.관심 있는 사람은 스스로 테스트해 보세요.

React의 결과

v0.13.3

원시 테스트와 같은 버전.150ms에서 330ms까지 거의 오른쪽 어깨가 올라갑니다.
파란색 선은 일반 JavaScript를 처리하는 시간으로, 빨간색 선은 최종 DOM 업데이트가 완료되는 시간입니다.이 파란색과 빨간색 선 사이의 간격, 즉 DOM 업데이트에 걸리는 시간입니다.

이 폭은 거의 고정되어 있으며, 이것은 React가 검측 차분을 통해 DOM의 업데이트 횟수 (위치) 를 고정시킨다는 것을 증명한다.만약 그렇지 않다면, 사진 장수에 따라 빨간색 선은 끊임없이 멀어져야 한다.

v0.14.6

상승세에는 변함이 없지만 성능은 많이 개선된 것으로 보인다.

반복적으로 테스트를 하면 특히 사진 수가 적을 때의 성능이 안정적이어서 좋은 인상을 남긴다(v0.1.3과 비교).

원래 JS의 결과

약간의 혼란이 있었지만, 기본적으로 리액트의 1/2 정도의 처리 시간만 있으면 된다.오리지널 기사는 1200장 (건) 에서 이해할 수 없는 하락 (대폭적인 성능 개선) 을 관측했지만, 이 테스트는 비교적 솔직한 상승이었다.

MagJS의 결과

Y축의 축척에 주목합니다.자릿수가 다르다.MagJS와 관련해서는 신중하게 여러 차례 테스트를 진행했지만 대체로 같은 그래프였다.

솔직히 MagJS의 성능이 정확하게 측정되었는지는 아직 확실하지 않으니 이 결과를 너무 믿지 마세요.

전반적 비교

마지막으로 전체 처리 시간을 비교한 도표는 여기에 있다.

리액트는 성능이 개선됐지만, 반년 전과 같은 경향을 보였다.

보태다

원 보도에서 테스트를 하기 전에 "추상화는 원가와 일치합니까?"이런 문제.
In any case the question is not “Is React faster than
Vanilla?”, so much as it is about how much extra time React
is going to take to run, and thereby affect the user
experience. In short: is the abstraction worth the cost?
리액트가 기존 JS보다 빠른지는 물어볼 수 없다.왜 그랬을까
It strikes me that even if JavaScript itself is fast, there are two trees that React is going to have to diff to make some patches, and therefore going direct will be faster, provided I don’t trigger layout thrashing or some other horror.
그래서리덤을 데리고 차분 검사를 하는 이상 처리 시간에 아무리 발버둥쳐도 원래의 JS를 이길 수 없다.당연하죠.
그리고 원 보도에서 마지막으로 이렇게 정리했다.
It seems to me that developer ergonomics should be less important than our users’ needs, as painful as that can be for us developers. Despite the claims, React does seem to have significant performance implications, at least under certain circumstances.
솔직히 이거 읽다가 깜짝 놀랐어요.확실히 추상화를 통해 개발 효율을 높이면 개발자가 즐거워질 수 있지만 이로 인해 사용자의 이익에 손해를 끼치면 본말이 뒤바뀐다.이번 시험의 이유는 이 절에서도 자신을 반성하는 부분이 적지 않다.
MagJS에 관해서는 제가 받아들일 수 없기 때문에 판단을 보류합니다.좀 더 깊이 들어가야 할 상황입니다.

총결산

추상화는 원가를 수반한다.만약 그 원가가 사용자에게 전가된다면 걱정해야 할 사태다.특히 모바일 단말기의 성능 악화는 사용자를 멀리하게 할 수 있다.
어렵게 도입한 코믹 추상화로 서비스의 성능이 떨어지고 경쟁력이 떨어진다면 이런 블랙 유머는 없다.
그리고 성능 개선에 노력해야 할 때 그동안 쌓인 추상화는 기술 부채가 될 수 있다.
오해하지 마시기 바랍니다. 이 글의 목적은 리액트를 폄하하는 것이 아니라 MagJS를 추천하는 것도 아닙니다.
앞서 보도한 바와 같이 스스로 테스트를 해 결과에서 판단하는 과정이 중요하다.
그 결과 React의 성능을 허용 범위로 사용하는 경우도 있고, 무한 목록의 페이지에서만 React와 같은 혼합형 실시 방식을 사용하지 않는 경우도 있다.
플렉스도 자전거 주차장에 대한 논의를 시작했지만 그곳에서 완성할 수 있는 완벽한 추상화가 어디에서 비용을 발생시킬지 버림받았다는 인상을 남겼다.
나는 글의 단순성에만 치중하지 말고 여러 각도에서 검토하는 태도를 잊지 않기를 바란다.자계를 주입하다.