전산쟁이 Firefox 3.5 vs Chrome 2.0 2009/07/01 23:25 by 준경군

아기다리 고기다리던 파폭이 3.5 정식버전이 릴리즈 됐습니다. 최근 맥북이(파폭이 사용)를 잠시 접어두고 윈도우 머신을 사용하게 되면서 구글의 크롬이을 기본 브라우저로 사용하던 중이었는데, 이것도 막상 쓰다보니 살짝 괜춘하더라 이겁니다. 그래서 고민을 때렸지요.

걍 윈도우에선 크롬이를 쓸 것인가? 이대로 놔둬도 상관이 없는 것인가? 이러한 고민을 없애고자 제 나름대로 간단한 성능 테스트를 해봤습니다. (많은 시간을 들이진 않았습니다.)



Acid3 Test
브라우저를 처음 깔면 결과는 별 관심도 없으면서 Acid3 Test를 띄워보곤 합니다. 현재 살펴본 각 브라우저의 점수는 크롬이 99점, 파폭이 92점93점(앞선 테스트가 살짝 잘못됐더군요.)입니다.

    

헌데 좀 이상한 현상을 발견 할 수 있는게, 크롬이는 처음 테스트를 띄우면 결과물은 살짝 깨지면서도 점수는 100점이라는 좀 아이러니한 결과가 나와버립니다. 그리고 '새로고침'을 해보면 결과물은 같은데 점수는 99점으로 깎이는 이상한 모습을 볼 수 있습니다. 반면 파폭이에서의 테스트 결과물은 외관상 크롬이보다 깔끔한데 점수는 92점93점이 나와버리는... 그래서 지금 어떤걸 믿어야 할지 좀 고민 중입니다.


Image editing in the browser
Firefox 3.5가 나오기 이전부터 Mozilla측에서 TraceMonkey 성능의 우월성을 증명하기 위해 공개했던 테스트가 있었습니다. 'Image editing in the browser'라는 이름의 테스트인데 눈에 띌 정도로 파폭이가 앞선 성능(제 컴 기준 3~4배 정도의 차이로 파폭이 우수)을 보여주고 있습니다.

    

그리고 실제로 구글 Docs를 비롯한 각종 무거운 사이트들에서도 파폭이가 살짝 우월한게 아닌가 싶을 정도로 반응속도가 좋았습니다. ('모아찍기'의 위력이 아닌가 의심 중) 덕분에 한동안 '어라? 이거 역전한거?'라는 생각을 가지기도 했었습니다.


SunSpider JavaScript Benchmark
앞선 테스트에서도 나름 만족할만한 성능이라는 걸 입증했고, 출력물도 점수가 떨어져도 제대로 보이는 것이 우선이라는 생각에 나름 파폭이에 긍정표를 던져주려고 했었습니다만, 또 다른 테스트에선 어찌될지 모르겠다는 생각이 들어서 리뷰어들이 흔히들 애용한다는 WebKit 프로젝트 사이트SunSpider JavaScript Benchmark를 돌려봤습니다.

    

비교적 긴 시간동안 테스트를 하는데 결과는 역시나 크롬이의 우세였습니다. 그럼 그렇지.. 속도에 관해선 이상하게 조용한 모질라측의 홍보가 눈에 거슬린다 했더니 역시나 그 이유를 이 테스트에서 말해주네요.


V8 Benchmark Suite
웹브라우저 테스트라면 또 유명하신 분이 V8 프로젝트 사이트에서 내놓은 V8 Benchmark Suite입니다.

    

이 테스트에서도 역시 크롬이가 우세한 결과를 내놓는군요.


Web Browser Javascript Benchmark
앞선 몇개의 테스트는 한쪽 웹브라우저와 밀접한 관련이 있는 테스트라 다소 신빙성이 떨어질 수 있겠다는 생각이 들어서 조금은 중립적인 사이트를 찾아봤습니다. Celtic Kane이라는 사이트'Web Browser Javascript Benchmark'라는 놈이 있어서 돌려봤는데 이건 또 경우에 따라서 수치가 엎치락 뒤치락하는 호각세를 보여주었습니다.

참고로 저같은 경우는 동일한 환경을 만들어 놓고 테스트를 반복적으로 실행시켜 수치를 비교해봤는데 이 값들이 생각보다 편차가 좀 큰 편이라 따로 스샷을 뜨지는 않았습니다.


Memory
파폭이의 고질적인 문제로 지적받는 메모리 문제입니다. 이번 버전에선 전 버전에서도 살짝(?) 남아있던 메모리 문제가 어느정도까지 해결됐는지는 파악되지 않았습니다만, 일단 그것은 제외로 하더라도 기본적으로 먹고 들어가는 양에서 차이가 있더군요.

테스트는 빈 페이지를 띄운 첫 화면에서의 메모리 양과 SunSpider JavaScript Benchmark를 돌린 후의 용량을 비교해봤습니다.

  • 파폭이
    빈 페이지 상태에서 29MB. 아무것도 안했는데 갑자기 33MB대로 이유없이 상승. (Max 59MB까지 경험 - 원인불명) 테스트 후에는 9MB정도 증가.
  • 크롬이
    이상하게 프로세스가 두개씩 뜸. 새 탭 페이지에선 22MB + 15MB, 빈 페이지는 24MB(곧 18MB대로 급감소) + 9MB, 테스트 후 24MB + 16MB 정도로 증가.

파폭이의 부가기능은 하나도 설치가 안된 상태이고, 메모리 상태는 윈도우XP의 작업관리자로 확인했습니다. 제 불찰로 스샷을 따로 챙기질 못해 글로만 적어놓으니 이점 양해바랍니다. (...)


결론
제가 제시한 테스트들에서 보여준 결론들은 대부분 크롬이의 우세판결을 향하고 있다는 점을 발견하실 수 있을겁니다. 다만 걸리는 점은 제가 너무나 성능에 치우친 테스트만 하기도 했거니와 그 성능상의 차이도 정확히 어느 부분에서 발생하는 것인지 파악조차 하지 않았다는 점이 결론의 모호성을 자초할 수 있겠다는 생각이 들었습니다. 따라서 섣부른 결론을 내리는 것이 다소 위험할 수 있겠다는 생각은 가지고 있습니다.

하지만 객관적으로 봤을 때, 특히 '성능'에 한정된 부분에 있어서 만큼은 크롬이에게 손을 들어줘야하는게 맞지 않겠나하는 생각입니다. 보다 객관적이라 할 수 있는 테스트들이 제시되기 전까지는 적어도 파폭이의 성능상 우위를 증명하기는 힘들것이라는 생각입니다.

트랙백

이 글과 관련된 글 쓰기 (트랙백 보내기)
TrackbackURL : http://ssmim101.egloos.com/tb/2361964 [도움말]

덧글

  • xeraph 2009/07/02 11:00 # 답글

    여전히 성능 부분은 체감할 수 있을 정도의 크롬 우세임 -_-
  • 준경군 2009/07/02 12:29 #

    제 컴에서 체감성능은 거의 비슷해요. 처음엔 파폭이가 더 빠른가도 의심했다니까요. -.-
  • polomerria 2009/07/02 20:36 # 삭제 답글

    크롬은 매 탭마다 다른 프로세스를 띄웁니다.
    탭 하나 죽을 때 다른거 안 죽게 하려고 그런 구조로 만들었다고 하죠.
    즉 탭이 늘면 늘수록 프로세스도 늘어나는 비극이 있죠..
  • 준경군 2009/07/03 00:49 #

    탭이 늘어날수록 프로세스가 늘어나긴 하지만 요즘같은 멀티코어 시대에 어울리는 프로세스 모델이라고 생각하고 있습니다.
    더불어 그 프로세스들이 잡아먹는 메모리 양을 합쳐도 같은 수의 페이지를 띄운 파폭이보다 작다면 문제될건 더더욱 없지요. (직접 테스트는 못해봤지만 작을거라 예상하고 있습니다.)
  • 홈쥬인 2009/07/04 11:36 # 답글

    앗싸 오늘도 박보영 링크 발견!!!!
  • 준경군 2009/07/04 23:48 #

    아 쫌... 쉬잇~!!! -_-
덧글 입력 영역