2006/08/05 14:51 Developer
자바스크립트(Prototype) 코드 스피드 밴치마킹
평소 아주 좋은 글을 많이 포스팅하시는 파이어준님의 블로그에서 porototype.js와 원시코드간에 퍼포먼스 벤치마킹 포스트를 보고 인용해서 글을 남긴다.
자바스크립트(Prototype) 코드 스피드 밴치마킹
http://firejune.com/index.php?page=2
테스트에 사용된 Prototype 프레임웍 라이브러리의 버전은 Scriptaculous1.6.1에 포함된 1.5.0_rc0이며, 브라우저는 파이어폭스2.0b, 시스템사양은 Pentium4, 3.00GHz입니다.
// 타임체크 함수
function timeChecker() {
var befor, loops, after, tpo, tet, result
before = new Date()
loops = 500 //루프 수
for (var i=0; i<loops; i++) {
Element.update('element', '내용')// 태스트함수
}
after = new Date()
tpo = Math.round(1000*(after-before)/loops)
tet = (after-before)/1000
result = 'Time per operation: '+tpo+', Total excuted time: '+tet; //결과값
throw(result)
//return result
}
timeChecker()
1. document.getElementById('엘리먼트').style.스타일 = '값' // (원시코드, 2라인) --> 1.14초
2. $('엘리먼트').style.스타일 = '값' // (2라인) --> 1.656초
3. Element.setStyle('엘리먼트', {'스타일:값의 배열x2'}) // --> 1.985초
4. $('엘리먼트').setStyle({'스타일:값의 배열x2'}) // --> 3.047초
일단 그럼 한번은 하는데, 얼마나 걸릴까 보자.
1. 0.000114초
2. 0.00011656초
3. 0.0001985초
4. 0.00030047초
이렇게 나온다는 얘기다.
하나의 웹페이지를 띄운다고 가정을 하면, 그 안에 위와 같은 DOM엘레먼트가 얼마나 쓰일지 모르겠지만, (만번은 안 쓰죠?) 1번으로 봤을때는 정말 경미한 수치다.
사실, 프로토타입에서 크로스브라우져부분을 제거하면 위에 수치보다는 더 빨라질수도 있고, 때로는 원시코드에 크로스브라우져를 위한 코드가 들어갔을때 비슷한 성능을 보일수도 있다. 크로스브라우져 부분을 고려해서 코드를 작성해야 더 올바른 코드가 아닌가 생각한다.
그리고, 리소스를 사용하는 부분이 서버쪽이면 사실 의미가 있는 숫자로 보일수도 있으나, 클라이언트쪽에서 리소스를 사용하기때문에, 무시(?)할만한 숫자로 보인다. 위와 같은 숫자로 prototype.js를 포기하기에는 너무 아쉬운 부분이 많기 때문이다.
눈깜짝도 안하는 사이에 일어나는 퍼포먼스를 튜닝을 해봐야 체감이 느껴지지 않을 것이다.
서버쪽의 부담을 덜기 위해서 성능이 좋은 클라이언트에 피씨에 오히려 부담을 일부러 안겨주는 상황도 있을수 있다.
과거에 prototype.js가 메모리릭이 존재한다는 이야기를 들었다.(1.5에서 해결을 했다고 하던데) 특히 DOM을 사용할때는 구조적으로 자바스크립트를 잘 짜야 좀더 최적화된 웹페이지를 만들수 있을 것이다.
http://www.codeproject.com/jscript/leakpatterns.asp
물론, 선택은 개발자의 몫이다. 파이어준님이 정확한 분석을 해준만큼 자신이 개발한 웹어플리케이션에 protoytpe.js를 이용한 자바스크립트때문에 성능저하가 발생을 한다면, 원시코드를 적절히 이용해서 튜닝을 하도록 하면 된다.
난 물론 편하게 그냥 사용하고, static한 변수를 사용해서 매번 호출되는 것을 줄이고, 메모리릭만 안생기게 주의를 기울일 것이다...^^
