msgbartop
If it ain’t broke, fix it anyway
msgbarbottom

28 Mar 07 개발자와 사용자의 ‘속도’차이

개발자들은 소프트웨어의 ‘속도’라고 하면 흔히 여러 벤치마크를 생각한다.  사람들이 Java가 느리다고 할 때, Java 개발자들은 HotSpot과 같은 기술로 Java를 빠르게 만들었다.  정말 최근의 JVM은 빠르다.  대용량 서버용 소프트웨어에 Java가 많이 쓰이는 이유 중 하나이다.  그런데도 applet은 거의 사용되지 않고 사용자들도 좋아하지 않는다.

사용자들이 느끼는 속도는 개발자들이 생각하는 속도와 다르다.  사용자들은 virtual function call이 어떻게 사용중에 profile되고 inlining되어 C++의 virtual function보다 빨라질 수 있는지에 대해선 관심 없다.  다만 그들은 Java 로고가 보일 때는 웹페이지가 늦게 뜬다는 것을 알 뿐이다.

사용자들의 PC는 개발자들의 PC와 다르다.  CPU의 GHz만 높고 메모리는 부족한 대기업 PC에 시작 프로그램은 20개쯤 등록되어 있고 지금 보고 있는 웹페이지에서도 온갖 그림과 플래시 때문에 하드 디스크는 이미 한참 swapping하고 있는 중이다.  더군다나 그 하드 디스크는 defrag한지가 몇년쯤 되었고 90% 이상 용량이 차있어서 기본 defrag tool은 쓰지도 않지만, 쓸 수도 없다.  이런 PC에서 JVM이 뜨면서 수십 MB를 새로 확보하려면 수십초가 걸려도 이상하지 않다.

아무리 PC 사양이 좋아졌다고 해도, 보통 사용자들의 PC는 느리다.  CPU가 느리다기 보다는 메모리가 부족하고 fragment된 하드 디스크가 느리다.  따라서 메모리 footprint를 줄이는 것이 무엇보다도 중요하다.  매크로미디어는 이런 점을 잘 알고 있었고 Sun은 그렇지 못했다.

최근 FLEX2를 써보기 시작했다.  Java와 비교할 때 장점도 있고 단점도 있다.  ActionScript의 실행속도가 아무리 빨라졌다고 해도 JVM에 비교할 수는 없다.  하지만 사용자가 느끼는 속도 차이는 그게 아니라 큰 부담없이 뜨는 플래시와 이미 ‘느리다’는 느낌으로 조건학습되어버린 Java 로고의 차이이다.

Reader's Comments

  1. |

    AVM(ActionScript VM)도 중간코드로 변환되고 JIT Comilation도 하니까 분야에 따라 JVM보다 빠른 부분도 있지 않을까요?
    그리고 Flash의 성공요인은 ‘Browser의 blocking이 없기 때문이 아닌가’라고 개인적으로 생각합니다. 웹페이지에 embed로 avi나 wmv 를 넣으면 페이지가 뜰때 브라우져의 모든 UI가 block이 되고 applet의 경우도 마찬가지 잖아요? 파일 포맷이나 애플릿 자체의 문제라기 보다는 아마도 ActiveX(Applet도 IE입장에선 ActiveX니까) 클래스 로딩이 오래 걸려서일텐데 Flash는 이게 기가 막히게 빠라서 편안한 느낌을 주는듯 합니다. JVM의 startup time이 느린것이 JVM의 용량이 큰것이 원인이라 말할 수는 없지만 영향을 받는건 사실인데 이에 대한 연구도 진행중이라 하더군요. JVM로딩시 나오는 자바컵 애니메이션은 일단 애플릿자리에 img tag를 보여주고 안보이게 로딩하다가 init되어있는지 javascript로 polling 하는 방법을 쓰면 많이 개선되지만 그래도 browser blocking은 막을수가 없더군요.

  2. |

    물론 부분적으로 빠른 경우도 있겠지만 전반적으로는 dynamic한 부분이 많기 때문에 JVM보다 느릴 것 같습니다. 벤치마크해 본 것은 아니구요.

    Blocking에 대한 말씀은 공감합니다. 아이러니한 것은, blocking이 가장 심한 PDF plugin을 만든 Adobe사가 Macromedia를 인수했다는 것이구요, Apollo가 PDF를 수용한다고 할 때 가장 우려되는 부분이기도 합니다.

    J2SE 7에선 startup time을 줄이는 노력을 한다는데, 이런 노력이 많은 경우 이를 위한 새로운 코드를 더하는 식인데다 이미 JVM이 많이 bloat되어 있는 상황이라 본문에서 얘기한 것처럼 메모리가 부족한 상태에서 대부분의 시간이 disk swapping에 소요된다면 이를 얼마나 개선할 수 있을지 모르겠네요. 저도 계속 클라이언트쪽에 Java를 써보고자 하는데 항상 startup time이 가장 문제가 되더군요.

  3. |

    Flash 9에서 HTTP나 DOM 처리 부분이 상당한 성능을 내던데 그 쯤에서 사용되는 API들은 뻔한것이니 그 부분은 native 처리를 하지 않았을까요?(전혀 근거 없습니다 ^^)
    말씀하신대로 전체적인 VM성능은 자바보다 느리겠지요.

    Adobe는 Flash의 빠른 startup time이 탐나서 인수한게 아닐까요? Flash paper 서비스를 봤더니 web view는 flash로 하고 PDF는 archive용으로만 사용하려 하더군요.
    Apollo도 깔아봤는데 속도가 역시 빠르더군요.

    Java 7에서 Java Kernel을 언급하신듯 한데 초기 VM download time말고 이미 설치되어 있을때의 startup time이 느리다는것도 인지하고 있던데 개선이 있으리라는 막연한 기대 ^^.

    그리하여, 저도 Flex를 공부중입니다..T_T

  4. |

    웬만한 라이브러리는 native로 되어 있겠죠. 그렇지 않으면 dynamic한 언어들은 속도가 너무 안나니까요.

    Adobe가 매크로미디어 인수할 때 이유에 대해 한마디로 “Flash”라고 했다더군요. 요즘 Flash 비디오와 FLEX를 보면 인수 잘 했다는 생각이 듭니다. 물론 당시에 이 정도는 예상하고 값을 매겼을 것 같구요. FLEX는 분명히 한 영역 차지할 것 같은데 아직 Apollo는 잘 모르겠습니다.

    암튼 Flash는 보면 볼수록 얄미울 정도로 잘 하고 있습니다. 저희 모(母)회사에서도 경쟁하는 부분이 있어서 고민 많이 하던데 뾰족한 답이 보이지 않더군요.

Leave a Comment