자바스크립트의 특징 중에서 가장 독특한 것 성격들을 적었다.

아래 3가지를 이용하면 유연하게 빠른 개발을 할수가 있다. 나같은 경우는 과거 2002년에 deep하게 자바스크립트를 이용해서 개발을 시작을 했다. 처음에는 어려웠지만, 막강한 파워에 놀라웠고, 2004년 쯔음에 FCKEditor소스를 접하면서 충격적이었다.

Ajax 덕택에(?) 지금은 그 때보다도 더 인기있는 스크립트로 자리를 매김하고 있다. 더 많은 오픈소스들이 나와서 개발자들을 즐겁게 하고 있다.

특히, 메소드를 변수에 담을 수 있는 것과 prototype이라는 특성을 이용한 상속은 흥미롭다.
FCKEditor를 보면, 동적으로 스크립트르 구현한 파일을 선택을 해서 로딩을 하고, 로직을 처리하는 부분이 있다. 다형성을 구성을 할때 유용한 선택이었다.

클라이언트 브라우져를 위한 개발을 위해서 자바스크립트는 현재 최고라는 생각이 든다.

Higher-order functions
동적 타이핑(Dynamic typing)
Wrap up

Crossing borders: JavaScript의 특징
http://www.ibm.com/developerworks/kr/library/j-cb12196/index.html?ca=drs-kr

원문 :

Crossing borders: JavaScript's language features
http://www-128.ibm.com/developerworks/java/library/j-cb12196/index.html

Posted by ologist
 TAG javascript

평소 아주 좋은 글을 많이 포스팅하시는 파이어준님의 블로그에서 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한 변수를 사용해서 매번 호출되는 것을 줄이고, 메모리릭만 안생기게 주의를 기울일 것이다...^^

Posted by ologist
그냥 어딘가에 비슷한 내용을 스크랩한거 같은데, 여기다가 다시 포스팅!!
나중에 찾아보기 쉽게...^^

팝업창을 내용에 맞게 크기 자동조정하기
http://blog.naver.com/haruma95/80016275058
Posted by ologist
 TAG javascript
이전버튼 1 이전버튼

블로그 이미지
ologist

공지사항

Yesterday171
Today52
Total34,795

달력

 « |  » 2012.02
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

최근에 받은 트랙백

글 보관함