Flash와 Flex에 와 함께 찾아온 RIA 기술에 발전은 MS의 실버라이트와 Oracle의 JavaFX 과 함께 시장에서의 기대치를 극대화 했었다. 하지만 현재에 이르러는 RIA 기술 전반에 걸쳐 주춤하고 있는듯 해 보인다. 

Technology Radar 2010 소개글인 "JavaScript 필수 프로그래밍 언어로!!" 에서도 발표 하였지만 RIA 기술은 채택(adopt) 에서 접근(access) 단계로 무관심해도 될 단계로 다가가고 있다.  

최근 국외 indeed.com에서 RIA 기술 Job Trend 검색결과의 추이를 살펴 보니 Adobe의 Flex의 기술보다 보다 뒤늦게 2007년에 시작된 오픈 웹 기술인 JavaScript로 개발된 Ext JS 프레임워크가 Adobe Flex를 뛰어 넘었을 뿐 아니라 시장에서의 개발자 수요가 급격히 상승하고 있다.



http://www.indeed.com/jobtrends?q=javafx,+extjs,+adobe+flex&l=&relative=1

도대체 뭐길레 뜬금없이 JavaScript 프레임워크와 Flex와 JavaFX와 비교 할까?


Ext JS의 특징
Ext JS는 오직 JavaScript와 CSS로만 이루어진 JavaScript 프레임워크로 Flex가 갖는 대부분의 기술을 구현하고 있을 뿐 아니라 Google Web Toolkit인 Ext-GWT 버전으로 Java 개발자도 웹을 통해 성숙한 UI(Tab, Toolbar, Menu, Grid, Drag & Drop,Tree, Panel, Chart 등)를 손쉽게 구현할 수 있다는 장점도 있습니다.
















뿐만 아니라 최근에 Ext Designer라는 Ext JS 전용 RAD(Rapid Application Development)를 발표하였습니다.  이 도구는 웹 상에서 데스크탑 애플리케이션과 동일한 GUI를 웹 환경으로 빠르고 손쉽게 옮길 수 있도록 지원할 뿐 아니라 일반적으로 웹에서 이러한 GUI를 구축하기 위해서는 하나의 기능만 구현함에 있어서도 상당한 양의 JavaScript나 CSS, HTML 코드가 필요하지만 예를 들어 델파이나 비주얼 베이직, C++빌더에서 처럼 Ext JS도 원시코드를 개발자가 직접 작성하지 않고 간단한 설정 만으로도 웹에서 다양한 GUI를 구축할 수 있도록 합니다.




Ext JS 2010 Roadmap
이미 예상했던 데로 Ext JS는 올해에 목표로 mobile용으로 가벼운 UI 엔진을 Ext JS 프레임워크에 탑재할 계획을 가지고 있습니다.(개인적인 추측이 였습니다.) 댜양한 컴포넌트를 추가적으로 개발하고 Ext JS 4.0에서는 HTML5 WebSocket, Offline 지원을 계획을 가지고 있고 HTML5의 가시화와 함께 HTML5에 대한 지원도 이어질 것으로 보입니다.

Appcelerator사의 Titanium 이나 nitobi.com에서 후원중인 PhoneGap과 같은 솔루션은 플랫폼(Andorid, iPhone, Symbian)에 상관없이 JavaScript만으로 Device API에 접근하여 내장(Native) 애플리케이션을 개발할 수 있도록 지원하고 있습니다.  

더욱이 이런 오픈 웹 기술은 플러그인 기술인 Flash나 Silverlight 에 비해 가볍기 때문에 데스크탑에 비해 부족한 디바이스에서도 높은 성능을 통해 사용자에게 좋은 경험을 제공할 수 있을 것입니다.


단점이 있다면
Ext JS에는 한가지 뼈 아픈 추억을 가지고 있는데 바로 초창기 유명한 라이브러리인 prototype, YUI, jQuery의 Adapter로 동작을 해왔었으나 독립적인 플랫폼으로 파생되면서 회사와 개발을 유지하기 위해서 유료화로 전환 되었습니다.

이로 인해 국내 시장에서는 단순한 JavaScript 라이브러리의 경쟁에 있어서 비교 우위를 선정하기 위한 대상 이였을 뿐 이였고 거기에 더해 유료 라이브러리라는 딱지가 붙어서인지 그간 관심 밖의 이야기였던게 사실입니다.
이로 인해 레퍼런스가 필요한 개발자들에게는 찾아보기 힘든 국내 이용 사례, 한글 레퍼런스 덕분에 전전 긍긍 Ext JS 포럼을 쥐 잡듯이 뒤져야 했습니다.


하지만 희망이 있다면...
국내의 시장에서 실상 RIA의 기술이 얼마나 요구되어질 지 알 수는 없으나 오픈 웹 기술은 날로 발전하고 기대치는 HTML5로 인해 연일 증폭되고 있습니다.  거기에 더불어 모바일도 뜨거운 감자로 그 니즈는 어디로 튀어 오를지 모른는 것입니다. 

이렇듯 웹은 링크를 기반으로한 웹 서핑과 정보의 유통이였다면 현재와 미래에는 플랫폼으로 발전되고 그 위에 오픈 웹 기술을 통한 응용 애플리케이션의 수요가 증가할 것이라는 것은 현재의 흐름인 것은 분명해 보입니다.

여기에 Adobe의 Flash, Flex의 기술보다 아직 가야 할 길이 많이 남은 MS의 Silverlight와 까마득한 JavaFX와 오픈 웹 기술인 Ext JS. 과연 그 흐름은 어떻게 될까?



신고
Posted by Rhio.kim

부제 : RIA를 위한 JavaFX 그리고 그의 진화

첫번째 세션에는 Prototype.js 저자 이신 김영보 선생님의 MethodChain과 Ajax 애플리케이션 아키텍처에 대한 내용이였습니다. 

하나의 점으로 시작한 이번 PT는 원리와 개념적인 설명부터 이어졌고 작은 점 하나의 의미는 보는 사람들에 따라 다르고 이 점이 아키텍처에 비추어 설명해 주셨습니다.

 


좀 다른 면이 있지만 <쎙떽쥐페리의 어린왕자 中에서> 코끼리를 삼킨 보아뱀과도 같다 라는 느낌을 받았습니다.  

아키텍처의 본질은 작은 점으로 시작되었지만 그 깊이는 알 수 없이 깊어 수많은 문제점에서 유연하게 대처하고 그 넓이는 무한히 넓게 확장성을 갖어야 한다는 의미를 담고 있었던 거 같습니다.

“새소리, 물소리” 
군인은 지도를 보면 새소리와 물소리가 들려야 한다 라는 선임하사의 말을 연상하시며 역시 아키텍처에 사전적인 것이 아닌 본질을 이해하기 위한 설명이 이어졌습니다. 

이어 설명한 HTML, CSS, DOM, JavaScript, XML, JSON, Ajax 까지 Ajax Application를 위한 기본 도구(언어, 디자인 등)들이 갖는 일반적인 특징과 기술적인 특징에 대해서 간략하게 설명했고. Ajax Application에서 getElementById()가 갖는 개념에 대한 중요한 포인트를 지적하였는데 간단히 넘어가서 다시 한번 언급하자면

var dom = document.getElementById( ‘domBook’ ); 
위의 코드가 갖는 개념, 목적, 관련 기술에 대해 정확히 알아야 한다는 것 이였다.

짧고 간단하게 집고 넘어간 부분이지만 Ajax Application 개발에 있어서 가장 중요한 부분이라 생각합니다..  우리가 많이 사용하고 있는 Porototype, jQuery, Script.aculo.us와 같은 라이브러리들 역시 이런 도구들의 원리와 본질을 잘 파악하고 있고 발전에 잘 대응하고 있기 때문에 성공한 JavaScript 라이브러리도 탄생할 수 있었을 것입니다.

Framework의 범주는 주요 라이브러리들과 MethodChain에서 기술적으로 고려하였던 부분을 비교해서 간락햐게 설명하셨데 MethodChain도 범주에 속한 조건(?)들을 대부분 만족하고 있는 것 같습니다.  하지만 많은 라이브러리가 이미 기본 범주를 뛰어넘어 RIA를 위한 좀더 나은 프레임웍 이상으로 발전해가고 있죠.  빨리 MethodChian도 세계적인 라이브러리들에 동일 선상에 위치하도록 발전되었으면 하는 바램입니다.

이로써 국내 오픈 JavaScript 라이브러리가 3개가 되었습니다.
레이쥬님 swaf 2.0 - http://reizes.egloos.com/ (개발 중단 하신 듯)
김영보님 MethodChain - http://www.methodchain.com/ 

마지막으로 Framework의 핵심은 "접근성과 확장성" MethodChain이 풀어야할 숙제들 중에 하나가 아닐까 생각이 듭니다.   jQuery가 세계적인 라이브러리가 된 것은 바로 두 가지 “접근성”, “확장성” 의 두 마리 토끼를 잡기 위해 노력했기 때문일 것입니다.

jQuery의 문서화가 꾀 잘되어있고 이는 개발자들이 쉽게 개발에 참고할 수 있는데 큰 도움을 주엇습니다.  그로 많은 개발자들이 확장기능이나 플러그인을 개발하여 공유하는 커뮤니티가 형성되다 보니 점차 jQuery의 사용률은 높아갔던 것입니다.  더불어 노키아, MS 등과 같은 기업에서도 웹 런타임 환경으로 임베드 되는 것들이 jQuery를 세계적인 라이브러리로 만드는데 보탬이 되었습니다.

이번 1세션에서는 MethodChain 에 대한 기술적 이슈보다 Ajax Application 아키텍처에 대한 기본으로 가져야 할 사상에 대해서 좀더 이해할 수 있는 시간이 되지 않았나 싶습니다.  

다른 주요 라이브러리와 MethodChian에 기술적인 비교에 대한 내용이 이어졌지만 실제 구현이 아닌 Firebug를 통한 코드 Trace를 하여 설명하기가 난해하군요. ^^;

MethodChain를 포함 대부분의 JavaScript 라이브러리가 갖는 기능들 중 MethodChain이 다른 라이브러리들 보다 좀더 개선된 메커니즘을 갖는 다는 내용이였습니다.
PT자료를 보시면 어떤 부분에서 차이가 있는지 간략하게 정리가 되어있으니 좀더 자세한 내용은 JCO의 PT 자료를 참고하면 됩니다.

시간이 여유로웠다면 여러 JavaScript 라이브러리들의 차이점들에 대해서 자세히 알 수 있었을 텐데요. 아쉽습니다.



제 2세션 JavaFX : RIA를 위한 새로운 플랫폼
이번 세션을 많은 분들이 기대가 컸던 것 같습니다.  새로운 플랫폼에 대한 관심도도 관심도지만 발표자가 신상철 박사님이라는 것 때문이였는데요.  신상철 박사님의 히스토리를 보니 열정이 대단하신 분이라고 생각이 들었습니다.  이번 세션을 통해 처음 뵈었지만 발표하는 내내 정말 열정이 묻어 나왔던 시간이였습니다.  

모든 PT가 영어로 되어있고 중간 중간 영어를 사용하신다고 하시더니 문장만 영어가 아니였지 60~70%는 영어를 사용하시더군요.. 새로운 용어도 있어서 생소했지만 그래도 적응할 만 했습니다.

신상철 박사님은 http://www.javapassion.com 을 통해서 자세히 만나보실 수 있습니다.
대부분의 컨퍼런스 참여자가 개발자일 것이라는 배려로 개념적인 부분들은 중요한 부분만 집고 넘어갔습니다.  JCO의 PT자료를 참고하시면 JavaFX의 특징에 대해서 쉽게 이해하실 수 있고 위에서 언급한 사이트에서 JavaFX의 좀더 상세한 강좌를 볼 수 있다고 하니 관심있는 분이라면 꼭 챙겨 보시기 바랍니다.

 

JavaFX Script의 특징
• Declarative, statically-typed scripting language
• Facilitates rapid GUI development
• Many cool, interesting language features
• Runs on Virtual Machine for the Java™ platform
• Deployment options same as Java programs
• Fully utilizes Java class libraries behind the scenes
• For content designers and Media engineers

를 소개로 실제 구현을 위한 위의 내용을 세세히 설명해 나가기 시작했습니다.
JavaFX Script라고 해서 그런지 왠지 JSON(Javascript Object Notation)과 별반 달라 보이지 않았다. PT자료를 보시면 아시겠지만 표기법의 차이가 조금 있을 뿐 매우 흡사해 보였습니다.  그 뒤에 보지 못한 다양한 기술들이 있겠지만 ^^;

그외에 Binding 이라는 개념에 있어서는 Callback 함수와 유사한 느낌을 받았지만 JavaFX에서는 bind 라는 메커니즘을 사용한 것 같습니다.



PT자료 소스코드 발췌
// Code in the previous slide
// The bind keyword, placed just before the invocation of makePoint,
// binds the newly created Point object (pt) to the outcome of the
// makePoint function.
var myX = 3.0;
var myY = 3.0;
def pt = bind makePoint(myX, myY);
println(pt.x); // 3.0

myX = 10.0;
println(pt.x); // 10.0

scale = 2.0;
println(pt.x); // 20.0

특별히 어려운 점은 없어 보입니다.  매우 손쉽게 접근할 수 있지 않을까 생각이 듭니다.  그 뒤로 이어지는 구현 설명으로 NetBeans에서 실제 준비된 예제와 디버깅을 통해서 개발자들에게 매우 쉽게 설명해 주셨습니다.


마지막으로 가장 인상 깊었던 내용이였는데 JavaFX를 이용한 모션 트위닝(Motion Tweening)과 이펙트(Effect) 예시를 아주 세세히 모든 단계로 쪼개어서 보여주셨습니다.

예제 소스를 JCO에 올린다고 하셨던 것 같은데 잘 모르겠네요.  위에서 언급한 사이트에서도 보실 수 있다고 하니 예제는
 그곳을 통해서 받아서 보셔도 될 것 같네요.




PT자료 소스코드 발췌
import javafx.scene.paint.Color;
import javafx.scene.Scene;
import javafx.scene.shape.Circle;
import javafx.stage.Stage;

Stage {
   title: "My circle"
   width: 100
   height: 100
   scene: Scene {
     content: [
        Circle {
          centerX: 50,
          centerY: 50,
          radius: 40,
          fill: Color.RED
        }
     ]
   }
}


3번째 세션 : RIA Technology Introduction
좋은 내용의 발표 내용이 많았지만 발표장 인터넷 환경 때문인지 조금 어수선했음 발표자료가 올라오는 데로 좀더 요약해서 올릴 예정



마감하며….
일단 발표하신 모든 분들과 컨퍼런스를 준비하신 분들께 감사함을 전합니다.  이번 컨퍼런스를 통해서 RIA 플랫폼을 위한 Java의 변화와 기술에 대해 간략하게 알 수 있게 되었던 기회가 되었던 것 같습니다.  

아쉬운 점은 Java개발자들에게도 상당히 많은 웹 개발 이슈가 있을 텐데 Java의 RIA 관련 세션이 3개 밖에 되지 않았다는 것입니다.  아마 내년엔 Java와 RIA는 더욱 끈끈한 관계로 세션이 개설되리라 확신을 합니다.  
그리고 세션이 주제별로 분류되다 보니 둘 중에 하나는 포기해야 하는 문제도 생기더군요. 

내년 내 후년에는 좀더 발전된 모습으로 개발자들에게 좋은 내용으로 다시 볼 수 있으면 좋겠습니다.  경품은 좀더 많아지고 여성 개발자들도 더욱 많이 올 수 있는 이벤트도 좀 ^-^
웹 앱스콘에 비해 여성분들이 몹시 작음은 솔로 개발자들에게 JCO 컨퍼런스에 참가에 대한 동기 유발이 그만큼 작아진다는 것 -.-;

고무님 말씀 했던처럼 10년 후에는 가족들과 함께 모이려면 쏠로 탈출구가 되어야 되지 않을까요?  (잘못된 해석인지 알지만 ^-^;;)



신고
Posted by Rhio.kim
부제 : garbage collection in javascript
자바스크립트 어플리케이션 메모리 관리라기 보다 가비지 컬랙션(Gabege Collection)과 클로져(closure)와 순환참조(circular reference) 의 관계에 대한 글에 가깝습니다.


중간 중간 정리하면서 가비지 컬랙션에 대한 참조한 블로그가 있었는데 까묵었습니다. ^-^;


간단 명료하게 결론부터 정리합니다.
Javascript RIA 개발 시 간과해서는 안되는 중요한 부분중에 한가지 입니다. 
바로 메모리 관리 Memory Management입니다.


  이미 여러 javascript로 RIA 개발 경험이 있는 개발자라면 뼈저리게 느끼고 있을 것입니다.
못느꼇다면 꼭 한번 브라우저를 띄우고 개발해 놓은 요소들을 메모리 테스트를 해보시기 바랍니다.

  그리고 윈도우 어플리케이션 개발자라면 이 메모리 관리에 대해서 매우 예민한 부분이 아닐 수 없습니다.  윈도우 어플리케이션도 아닌데 메모리 관리를 해줘야 한다니 그냥 웃고 넘어갈 분들도 계시겠지만 RIA 개발하려는 모든 분들께 메모리 관리에 대한 중요성을 전달해 주고 싶습니다.


가비지 컬랙션(Garbage Collection) ?
 힙heap영역에 할당된 더 이상 사용되지 않는 메모리인 가비지garbage를 가비지 컬랙터garbage collector가 다른 객체가 사용할 수 있도록 정리하는 것을 말합니다.

객체가 가리키는 참조 변수가 null이 지정되거나 객체가 더 이상 참조하지 않게 되었을 때 가비지 컬랙터의 후보가 되며 이러한 객체들은 가비지 컬랙터에 의해 메모리를 반환하게 됩니다.


가비지 컬랙션의 대상
1. 객체에 null 값이 대입되었을 때
    e.g.   var dat = new Date();
                  dat = null;
2. 참조변수에 다른 객체가 대입될 때
    e.g.   var dat = document.getElementById(‘rhio’);
                  dat = 29;
3. 메소드의 수행이 끝났을 때
    e.g.   function func() {
            var dat = document.getElementById(‘rhio’);
            //do something
          }

가비지 컬랙션과 순환참조에 대한 좋은 글  옷장수님 블로그#가비지 컬렉션의 이해

사용자 삽입 이미지
자바의 가비지 컬렉션은 자바가상머신Java Vitural Machine에서 알아서 처리하지만 개발자에 의해 직접 가비지 컬랙션을 수행 요청을 할 수 있습니다.  하지만 javascript의 경우에는 따로 개발자에 의해 가비지 컬랙션의 작업 수행 요청할 수 있는 매커니즘이 존재하지 않습니다.

Javascript는 주기적으로 가비지 컬랙션의 대상에 대한 리소스 반환 작업을 수행하게 됩니다.

IE 브라우저의 경우 순환참조Circular Reference 발생과  클로져 형성으로 메모리 누수에 대한 심각한 문제가 시작됩니다.   Javascript에서의 순환참조(Circular Reference)라 함은 Javascript 객체가 DOM 객체에 대한 레퍼런스를 포함하고 그 DOM 객체가 javascript 객체의 레퍼런스를 포함할 때를 말합니다.

위의 문단이 자바스크립트에만 순환참조가 있다라는 글로 오해될 수 있을 것 같아 살짝 수정 및 아래 내용을 추가합니다.  일반적인 순환참조(circular refrenece)에 대한 설명이 더욱 필요할 것 같네요.  (옷장수님이 의견 주셨습니다.)

일반적인 순환참조(Circular Reference)란?
참고 :
    http://en.wikipedia.org/wiki/Circular_reference
    http://en.wikipedia.org/wiki/Reference_counting


사용자 삽입 이미지

위의 예제는 흔히 우리가 알고 있는 javascript의 순환참조가 발생되면서 메모리 누수현상을 단편적으로 설명할 수 있는 예시가 됩니다.

div는 DOM 객체의 레퍼런스를 담고 있습니다. 이 DOM 객체를 outerFn 가 첫번째 인자로 취하여 DOM 객체에 func라는 프로퍼티property  javascript의 익명함수anonymous function 를 참조reference하게 합니다.

이 자체가 메모리 누수라 할 수는 없지만, 위와 같은 패턴은 경우에 따라(위와 같은 작업이 반복 적으로 수행될 때) 심각한 누수 현상을 발생할 수 있습니다.  이 말은 곧 가비지 컬랙션에 의해서 메모리 반환을 하지 못하는 상황에 빠지게 됩니다.

  Javascript의 가비지 컬랙터의 경우 클로져가 형성된 것들을 관리하며 혼돈하지 않아 가비지 컬랙션에 대해 메모리 반환을 하지만 불행히 IE의 경우 DOMJScript가 관리하지 않아 위의 예시와 같은 순환참조와 클로져에 대해 몹시 둔감합니다.  그만큼 메모리 누수 현상이 매우 심각합니다.

 
이번 IE8이 릴리즈 되면서 그에 대한 마이그레이션 팁이 나왔습니다. 그 역시 DOM과 Javascript의 순환참조에 대한 이슈를 대부분 언급하고 있습니다.  그에 대한 테스트와 테스트 결과에 대해서 다음에  간단한 포스팅을 하도록 하겠습니다.


참고
http://www.crockford.com/javascript/memory/leak.html
http://www-128.ibm.com/developerworks/web/library/wa-memleak/

신고
Posted by Rhio.kim
사용자 삽입 이미지
Ajax 와 DOM 스크립팅에 현재 가장 이슈가 되는 것은 아무래도 고성능을 낼 수 있는 웹 어플리케이션을 만들 수 있느냐라고 생각합니다.

웹 자체는 가벼우면서 사용자들에게 손쉽게 다가갈 수 있고 사용자들에게 가장 쉽게 어필 할 수 있는 것 역시 웹(web) 입니다.

최근 RIA 개발에 Ajax가 가미되면서 Client-side 와 Server-side 가 완전히 분리되고 Client 에서는 UI에 전념할 수 있게 되었습니다.

하지만 이에 "대화형 웹 어플리케이션"을 위한 Ajax와 DOM 스크립팅이 그 만큼 중요하게 되었는데요.

크로스브라우징, 사용자 리소스 최적화 등의 이슈가 되고 있습니다. 그렇게 좀더 가볍고 저사양에서도
또한 글로벌 스탠다드가 되기 위하여 최고의 퍼포먼스를 낼 수 있는 RIA 설계가 중요하게 되었습니다.

우리는 IE, FF, Opera, Safari 의 크게 4가지의 브라우저를 기본으로 크로스 브라우저에 대응합니다.
이에 몇가지 브라우저별 퍼포먼스를 비교해봅니다.


DOM 스크립팅 퍼포먼스 (HTML DOM Operation Performance)
                                        IE7             FireFox            Safari       
HTML DOM Operation Time(ns) % Time(ns) % Time(ns) %
Change text using innerHTML 469.0 9979% 234.0 6000% 109.0 7032%
Create a text node on HTML Dom 1093.0 23255% 156.0 4000% 110.0 7097%
Change the class name of an element 422.0 8979% 47.0 1205% 109.0 7032%
getElementById 86.8 1846% 15.7 401% 3.9 252%
getElementsByTagName("div") 153.1 3257% 18.0 462% 5.5 352%
getElementsByName 93.8 1995% 44.6 1142% 4.7 303%
placeDiv.getAttribute("id") 29.7 632% 46.8 1200% 5.5 352%
placeDiv.attributes["id"] 31.3 665% 225.0 5769% 6.3 403%

IE7의 결과는 UI 개발자의 손목에 수갑을 채우고 있습니다. 꼭 이런 문제뿐만 아닙니다.
IE8에는 많은 문제가 해결되고 표준에 의거하여 개발에 임했으면 합니다.



eval function의 수행 퍼포먼스(2번)
IE7 172ns and 94ns
FireFox 546ns and 749ns
Safari 9.4ns and 22.7ns

과연 eval은 크로스 브라우징 대응에 있어서 사용을 줄여야합니다.


Object 생성 수행 퍼포먼스
“var myObject = new MyObject (17, 250);
“var slowCar = {m_tireSize:17, m_maxSpeed:250};”

IE7 11.7ns and 8.6ns
FireFox 23.4ns and 23.4ns
Safari 3.2ns and 2.4ns

Ajax 개발 시 Server-side 에서 JSON 을 받아올 경우 Firefox의 경우 Object화 하여 사용할 경우
경우에 따라 퍼포먼스에 많은 영향을 미칩니다.


in 수행 퍼포먼스
IE7 10.3ns
FireFox 62.8ns
Safari 7.6ns


Firefox 도 Ajax 개발 시 경우에 따라 상당히 느려지는 부분을 보이고 있습니다.
하지만 IE6의 경우보다는 매우 양호합니다. IE6의 경우는 대부분의 Ajax 개발 관련 Performance 테스트에서
몇 백 퍼센트의 차이를 보이고 있습니다.
특히 IE의 경우 String 퍼포먼스에서 매우 낮은 결과를 보입니다.

DOM 스크립팅시에 우리는 DOM 구조를 일일이 생성하는 것 보다 String innerHTML을 자주하게 활용하는데요.
IE의 경우 퍼포먼스에 지대한 영향을 미칩니다.
그래서 우리는 Array 를 이용 string buffer 기능을 사용하여 효율적으로 처리하고 있지만 전체적으로 IE의
경우 String에 낮은 퍼포먼스를 보입니다.

마지막으로 Safari 의 경우 다른 브라우저들에 비해 상당히 안정되고 최고의 퍼포먼스를 자랑하고 있습니다.
역시 아직까지 다른 브라우저에 비해 기능 차이가 있기 때문입니다.

체감하는 렌더링 속도도 상당히 차이가 있음을 느낍니다.


Internet Explorer 7

      FireFox

     Safari

Description

Time (ns)

% of base

Time (ns)

% of base

Time (ns)

% of base

Normal Empty function call (Base Operation)

4.7

100%

3.9

100%

1.6

100%

Basic Function Calls







Function call using function.call(this)

5.5

116%

2.4

60%

1.6

100%

Normal Empty function using apply

5.5

117%

7.0

179%

2.4

152%

Normal Empty function using apply with 3 parameters

7.0

149%

7.1

181%

2.4

152%

Eval a function

172.0

3660%

546.0

14000%

9.4

603%

Eval an object

94.0

2000%

749.0

19205%

22.7

1461%

Basic Operations







Access Properties through a getter

13.3

282%

6.3

160%

5.5

352%

Access Properties directly

4.7

100%

3.2

81%

2.4

152%




 

 



Simple string concatenation

4.7

100%

2.3

59%

1.6

100%

Simple string compare

3.9

83%

2.4

60%

0.8

48%

Change string to upper case

11.7

249%

3.9

100%

4.7

303%

Replace string reg expression

12.5

266%

7.1

181%

9.4

603%

String concat with integer

7.1

150%

4.7

119%

2.4

152%

String concat with float

6.3

133%

4.7

121%

2.4

152%

Index of Bob in string, not found, length = 71

6.3

133%

6.3

160%

2.4

152%

Match of Bob in string, not found, length = 71

14.9

316%

25.0

640%

3.9

252%

charAt(10) in string

11.7

249%

6.3

160%

3.1

200%




 

 



Create object constructor initialized

11.7

249%

23.4

600%

3.2

203%

create simple object

8.6

182%

23.4

600%

2.4

152%



0%

 

 



Variable declaration

4.0

84%

2.3

59%

0.8

48%

Multiple variable declaration, multiple var

3.9

83%

2.4

60%

2.4

152%

Multiple variable declaration single var

3.9

83%

2.4

60%

1.6

100%

Variable declaration set to null

3.9

83%

2.4

60%

1.6

100%



0%

 

 



Variable assignment++

4.7

100%

5.5

140%

1.6

103%

Variable assignment + 1

5.5

116%

7.1

181%

1.6

100%




 

 



Four levels of property access

5.5

116%

5.5

140%

1.6

100%

Three levels of property access

4.7

100%

4.7

121%

2.4

152%

Two levels of property access

4.7

100%

4.7

119%

1.6

100%

One level of property access

3.9

83%

4.7

121%

1.6

103%



0%

 

 



Using the typeof function

3.9

83%

4.7

119%

1.6

100%

Array Operations







Array access

7.1

150%

7.0

179%

1.6

100%

Array index value change

3.9

83%

4.7

121%

1.6

103%

Empty Array index value change

8.6

183%

8.6

221%

6.3

403%

Empty Array add three values

10.2

216%

11.7

300%

3.1

200%

Empty Array with set size

11.0

233%

11.0

281%

3.2

203%

Empty Array using constructor

9.4

199%

25.8

662%

2.3

148%




 

 



Push element onto an Array

25.0

532%

6.3

160%

1.5

98%

Pop element of an Array

165.6

3523%

6.3

160%

249.7

16112%

Push element onto an Array

6.2

132%

7.1

181%

1.4

92%

Shift elements off the front of an Array

2030.0

43191%

5620.0

144103%

1250.0

80645%

Join the array into a string

125000

2659574%

47000

1205128%

16000

1032258%

Push element onto an Array

7.1

150%

7.0

179%

3.9

252%

Sorting of an Array

93.0

1979%

45.3

1162%

32.9

2119%




 

 



Math.max(7.25,7.30)

5.5

116%

4.7

121%

3.9

252%

Math.min(7.25,7.30)

5.5

117%

4.7

121%

3.2

203%

HTML DOM Operations







Change text using innerHTML

469.0

9979%

234.0

6000%

109.0

7032%

Create a text node on HTML Dom

1093.0

23255%

156.0

4000%

110.0

7097%

Change the class name of an element

422.0

8979%

47.0

1205%

109.0

7032%




 

 



getElementById

86.8

1846%

15.7

401%

3.9

252%

getElementsByTagName("div")

153.1

3257%

18.0

462%

5.5

352%

getElementsByTagName("spa")

142.2

3024%

18.8

481%

5.5

355%

getElementsByName

93.8

1995%

44.6

1142%

4.7

303%




 

 



placeDiv.getAttribute("id")

29.7

632%

46.8

1200%

5.5

352%

placeDiv.attributes["id"]

31.3

665%

225.0

5769%

6.3

403%

var atts = placeDiv.attributes; atts["id"].name

11.7

249%

18.8

482%

4.7

303%

var atts = placeDiv.attributes; atts.id.name

12.5

266%

18.8

482%

3.9

252%

Try/Catch







Function call using function.call(this)

7.1

150%

4.0

101%

2.4

152%

Try catch

7.1

150%

6.3

160%

5.5

352%

Try catch with throw

17.2

365%

7.8

200%

5.5

355%

Try catch finally

9.4

199%

7.8

200%

4.7

303%

Try catch finally with throw

16.5

350%

11.0

281%

6.3

403%

If statement and Date object







Create a date object

12.5

266%

10.2

260%

3.1

200%

Create a date object and call getDate()

28.1

598%

50.8

1303%

10.2

658%




 

 



The switch statement

4.7

99%

2.4

60%

2.4

152%

An if statement

4.0

84%

2.4

60%

2.4

152%




 

 



Simple if else

4.1

86%

2.2

56%

1.9

121%

turinary operator

3.9

83%

2.3

60%

2.0

131%




 

 



Compare of matching string ==

4.7

100%

7.1

181%

2.4

152%

Compare of matching string ===

4.7

100%

7.0

179%

2.4

152%

Compare of non-matching string

4.7

100%

3.9

100%

2.4

152%




 

 



Compare  TEST_INT == 5

4.1

86%

4.2

108%

1.7

111%

Compare  5 == 5

4.1

87%

2.0

52%

1.6

101%

Looping Performance Statistics







Loop through an array using in

10.3

219%

62.8

1610%

7.8

503%

Loop through an array using for (i++)

6.3

133%

10.6

273%

3.4

222%

Loop through an array using for (i < myArray.length)

6.2

133%

10.9

281%

3.1

201%

Loop through an array using for (i = 0; i < len; i++)

5.0

106%

4.7

120%

4.1

262%

Loop through an array using for (i = 0; i < len; i++)

5.3

113%

5.0

128%

4.1

262%

Loop through an array using while {i++}

5.3

113%

5.3

136%

4.7

302%

Loop through an array using while (i++ < len)

5.0

106%

5.0

128%

4.4

283%



원본 : http://www.coachwei.com/blog/_archives/2008/1/22/3480119.html
퍼포먼스 테스트 : http://www.rockstarapps.com/samples/performance/
신고
Posted by Rhio.kim
사용자 삽입 이미지

“RIA Cowboy” 자칭하는 James Ward 는 최근에 그의 RIA data 로딩 벤츠마킹을 정보를 업데이트 하였습니다.
텍스트 스트림에 대한 Gzip 압축에 대한 부분도 추가되었습니다. 그리고 이 테스트는 꾀 신뢰성있습니다.
다양한 방식으로 경유해서 오는 데이터의 퍼포먼스를 측정하였습니다.

이 테스트의 목적은 다양한 데이터 로딩 방법에 따라서 퍼포먼스, 데이터량 와 클라이언트 메모리 사용량을 측정해 입증하기 위함입니다. 또한 편견없고 신뢰성에 겨냥하고 있습니다.

아래 추가한 그래프는 James Ward 가 Flex 로 개발한 테스트 App입니다.
상당히 신뢰성 있다고 자부하고 있는것 같습니다.

JSON 을 사용하고 있어서 JSON 에 대한 부분의 퍼포먼스에 관심이 있었는데 기대치 만큼보이네요.


원본 출처 : http://www.jamesward.org/wordpress/2007/08/15/census-ria-benchmark-updated-with-gzip-and-laszlo/
벤츠마킹 : http://www.jamesward.org/census/

신고
Posted by Rhio.kim