July 2008

[dW리뷰]믿을 만한 자바 벤치마킹

원문기사: http://www.ibm.com/developerworks/kr/library/j-benchmark1.html

JVM에서는 핫스팟이나 GC 영향으로 작은 코드 단위의 성능을 측정하기 쉽지 않은데요. 코드 블럭 단위의 마이크로벤치마크의 정확성을 높이기 위한 요령과 고려해야할 요소 등에 대해 설명하고 있습니다.

실제로 유용한건 마이크로벤치마크를 위한 프레임워크를 제공하는 파트2겠습니다만 파트1에서는 기본적인 배경설명과 핫스팟이나 GC를 감안한 성능향상 팁(흔히 생각할 수 없는) 몇가지를 소개하고 있습니다.

    int result = 0;
    for (int i = 0; i < 1000 * 1000; i++) {    // outer loop
        for (int j = 0; j < array.length; j++) {    // inner loop 1
            result += array[j];
        }
        for (int j = 0; j < array.length; j++) {    // inner loop 2
            result ^= array[j];
        }
    }

    int result = 0;
    for (int i = 0; i < 1000 * 1000; i++) {    // sole loop
        result = add(result); // inner loop 1
        result = xor(result); // inner loop 2
    }

위의 두 코드는 같은 일을 하는 코드이구요. main()에 바로 구현된 것이어서 단 한번씩만 실행됩니다. 보기에는 위쪽 코드가 메소드 콜을 적게하기 때문에 더 빠를 것 같은데 핫스팟 적용을 위한 스택 내 치환(OSR)으로 인해 아래쪽 코드가 성능이 최대 두배까지 빨라진다고 합니다. 제 PC에서 테스트 해보니 각각 51.752s, 34.517s로 실제로 상당한 차이가 납니다. 뭐 배치 잡이 아닌 이상 일반적인 어플리케이션에서 딱 한번 호출하는 코드를 짤 경우는 많지 않겠습니다만.. 상식대로만 생각하면 안되겠다는 걸 보여주는 케이스인듯 합니다. ^^ 그외에도 생각지 못했던 재미있는 케이스가 많이 있네요.

요즘 하는 일이 메소드 수준의 성능 최적화가 많이 필요했는데 상당한 도움이 되는 기사였습니다. 좋은 기사와 번역 감사드립니다~

Development
dW Review

Comments (0)

Permalink

[dW리뷰] XUL(XML User Interface Language) 개발

원문기사: http://www.ibm.com/developerworks/kr/library/tutorial/x-xulintro/

파이어폭스3가 출시되면서 확장 기능 개발에 다시 슬쩍슬쩍 눈돌리고 있었는데요. 마침 developerWorks에 관련 튜토리얼이 올라왔네요! XUL 기반 스탠드얼론 어플리케이션 개발 이야기 입니다만.. 확장기능보다는 간단한 스탠드얼론 예제가 모질라 플랫폼 이해에는 더 좋을 것 같습니다.

파이어폭스3에는 오프라인 웹 애플리케이션 관련 기능도 추가되어서(Google Gears 같은 것) 더 재미있는 것이 많을 것 같습니다. 개발환경 셋업은 전보다 훨씬 쉬워지긴 했는데.. 자바스크립트가 능숙하지 않아서인지 여전히 간단한거 만드는 데도 시간이 많이 걸리네요.

그나저나 마소 7월호에 이클립스 플랫폼 소개 하면서 모질라 플랫폼이랑 살짝 비교한 부분이 있는데 -,.- 이클립스에 좀 명시적인 Extension Point/Extension이 있다고 해서 모질라 스타일의 동적 바인딩보다 우월하다는 것은 아닙니다. 장단점이 있는거죠. 뭐 기반언어가 각각 자바와 자바스크립트이고 메인 타겟 애플리케이션도 각각 IDE와 웹 브라우저다 보니 그에 맞춰 플랫폼 아키텍처도 따라간 것이 자연스러워보입니다. 그러나 저는 역시 이클립스 스타일의 명시적인 아키텍처가 취향에 맞네요. ^^

윈도우만 지원하는 WPF보다 훨씬 재밌는 XUL/모질라 어플리케이션 개발 좀 해보세요~ Gecko 렌더링 엔진이 워낙 빨라서… Gecko 기반 SWT가 나와도 충분히 돌아가지 않을까 싶은데.. Gecko 위에서 이클립스 돌린다면 재밌을 것 같네요.

참고 URL


dW Review

Comments (0)

Permalink

[dW리뷰] 한 눈에 보는 이클립스 가니메데

원문기사: http://www.ibm.com/developerworks/kr/library/os-eclipse-ganymede/index.html?ca=drs-kr

이클립스 3.4 통합 릴리즈 가니메데를 구성하고 있는 프로젝트들에 대해 간단히 살펴보는 기사입니다.

3.2 칼리스토, 3.3 유로파에 이은 세번째 통합 릴리즈입니다. 이클립스에는 하위 프로젝트가 너무나 많아져서 제각각 릴리즈를 하게 되면 사람들이 쉽게 접근하지 못할 우려도 있고, 프로젝트 들끼리 의존성을 갖고 있는 경우도 많기 때문에 1년에 한번 정도 출시일을 정해서 대표 프로젝트들의 통합 출시를 단행하고 있습니다. 또한 대표 프로젝트들을 용도에 따라 몇가지로 패키징을 해서 통합 릴리즈 이름 아래 대표 패키지들을 배포하고 있습니다.

3.2에서 통합 릴리즈가 나왔을 때는 간편해진 설치가 장점이었고 3.3에서는 Mylyn 기본 내장에 강력해진 웹 개발 도구가 강점이었다면, 3.4에서는 24개로 훨씬 늘어난 대표 프로젝트들이 예정된 출시일에 맞춰 나왔다는 것만으로도 자랑스러울 따름입니다. 뭐 약간 부족한 점이 있더라도 Equinox p2로 더 강력해진 업데이트 시스템 덕에 플러그인 추가 설치 또는 업데이트도 훨씬 매끄럽게 느껴지구요.

각 프로젝트의 개요는 원문기사에 잘 요약되어 있구요. 저 나름대로 눈에 띄는 점을 정리해보았습니다.

  • Subversive가 대표 프로젝트로 추가되었습니다. : Subclipse는 참 유감스럽겠네요.
  • 이클립스 플랫폼이 Mac을 더 잘 지원하게 되었습니다.
  • 모델링 관련 프로젝트들이 대거 추가 되었습니다.
  • RSE는 임베디드 개발 환경인지 서버 개발 환경인지.. 전혀 다를 것 같은 두 개발 환경을 Remote라는 이름 아래 함께 지원합니다.
  • Headless Update를 위한 발판인 Equinox p2
  • Mylyn에 이어 협업 강화를 위한 또다른 플랫폼이 될 ECF 추가

가니메데와 함께 즐거운 개발하세요~

Eclipse
dW Review

Comments (0)

Permalink

Plaxo로 완성한 캘린더 동기화 구성

Plaxo라는 SNS 서비스가 있습니다. 다른 서비스와 차별화되는 점은 제대로 된 동기화 솔루션을 제공한다는 것인데요. 아웃룩, 구글 캘린더, Mac, Windows Mobile, Yahoo 캘린더 등 매우 다양한 서비스에 대해서 꽤 잘 동작하는 동기화를 제공합니다. 한동안 안 쓰다가 딥뿔군의 난데없는 초대로 다시 써보고 있습니다. 예전에는 영문 이외 글자가 깨진다거나 하는 문제가 약간 있었는데 요즘은 거의 안정화가 된 듯 합니다.

그래서 다음과 같은 구성으로 확정했습니다.


200807061212.jpg

Plaxo 덕에 드디어 제 iPod touch에서 회의 스케줄과 회의실 위치를 볼 수 있게 되었습니다. 연동시키는 게 너무 많은 것 같기도 하지만… iCal과 iTunes Sync는 워낙 안정적인 서비스다 보니 전반적으로 다 잘 동작합니다.

  • Plaxo에서도 Mac을 지원하긴 하지만 회사 아웃룩 일정에 개인용 맥 캘린더 일정이 뒤섞이는 것이 싫다.
    -> Google Calendar를 거쳐 iCal 포맷을 활용한 One-way Sync로 구성
  • 구글 캘린더가 ToDo를 지원하질 않아서 ToDo Sync가 안되지만 어차피 iPhone, iPod Touch가 ToDo를 지원하지 않으니 소용이 없음.(대체 왜 아직도 ToDo가 없는건지?)
  • iPhone 발매되면 iPhoneOS 2.0 부터는 Exchange 서버 바로 붙일 수 있다고는 하지만 현재 회사에서는 iPod 무선랜 등록조차 시켜주지 않기 때문에 Exchage를 무선으로 열어주는 것은 기대하기 어려울 듯. 역시나 개인업무와 회사업무가 뒤섞이게 되므로 일단 현재의 구성이 최선

저는 PalmPilot 시절부터 Two-Way Sync 신봉자였는데..(네x버 주소록 아웃룩 동기화 서비스도 SyncML에 감명받아 딥뿔군과 쿵짝쿵짝 만들었습니다) 요즘의 결론은 iCal의 One-Way Sync를 양방향으로 두개 맺어 두는 쪽이 훨씬 안전하고 활용도도 높은 것 같습니다. 위의 예처럼 데이터 흐름을 제어할 수도 있고.. 아무래도 동기화하는 양쪽의 UI가 다르면 내용도 조금씩 달라질 수밖에 없는데 각자 자기 것만 편집하니까 데이터 훼손의 가능성이 없어집니다.(구글 Contacts 가 대표적, 내용이 계속 자동으로 추가되서 도저히 다른거랑 동기화하기가 민망) iCal을 조금 빨리 알았더라면 네x버 주소록 동기화 서비스를 Sync가 아니라 Casting으로 만들어서 지금까지 살아있을지도 모르겠는데요. 음 그럼 결국 Open API인데.. 연락처 공유 서비스로 발전해서 웹2.0 서비스가 되었을 수도 있겠군요! (망상 중.. 그래도 처음이자 마지막 서비스 기획?이었다보니^^)

그나저나 SyncML 나온지가 언젠데.. 동기화 서비스들은 아직도 안정화 단계라니 심한것 같습니다. (iPod은 예외, iPod 양방향 동기화와 Podcast 단방향 동기화 모두 아주 잘 되고 있죠) 특히 우리나라 사용자들은 이상하게 동기화 개념을 싫어해서… 서비스들이 동기화 관련해서 더 뒤처지는 것 같습니다.

Software

Comments (0)

Permalink