1P by GN⁺ | ★ favorite | 댓글 1개
  • Firefox가 오래된 SunSpider JavaScript 벤치마크에서 Chrome보다 빨라졌지만, 이 테스트는 이미 JetStream으로 대체된 성격이 강함
  • 최근 Firefox Nightly News는 SunSpider에서 Chrome을 앞서는 것으로 보인다고 밝혔고, 공개 수치도 Firefox 우위를 보여줌
  • 벤치마크 출처는 AreWeFastYet.com이며, 비교 대상은 약 10년 된 JavaScript 성능 테스트임
  • 더 최신이고 부담이 큰 JetStream 2.0에서는 Google Chrome이 Firefox를 여전히 쉽게 앞섬
  • 최근 한 달가량 Firefox는 SunSpider 실행 속도 외에도 HTTP/2 업로드 속도 등 여러 개선을 진행함

오래된 SunSpider에서 확인된 Firefox 우위

  • Mozilla 개발자들은 Firefox가 Google Chrome보다 SunSpider JavaScript 벤치마크에서 더 빠른 결과를 낸 점을 긍정적으로 보고 있음
  • SunSpider는 약 10년 된 JavaScript 벤치마크이며, 현재는 JetStream 벤치마크가 이를 대체한 상태임
  • 최근 Firefox Nightly News는 “We’re now apparently beating Chrome on the SunSpider JavaScript benchmark!”라고 밝힘
  • 공개된 수치는 Firefox가 이 오래된 JavaScript 벤치마크에서 Chrome을 쉽게 앞서는 흐름을 보여줌
  • 벤치마크 데이터는 AreWeFastYet.com에서 나온 것임

최신 벤치마크에서는 Chrome 우위가 유지됨

  • 더 새롭고 요구 수준이 높은 JetStream 2.0 벤치마크에서는 Google Chrome이 Firefox보다 여전히 쉽게 앞섬
  • Firefox는 최근 약 한 달 동안 SunSpider JavaScript 벤치마크 실행 속도를 크게 끌어올림
  • 같은 기간 HTTP/2 업로드 속도 개선을 비롯한 여러 작업도 함께 진행됨
  • 최신 Firefox Nightly 빌드의 변화는 Firefox Nightly News에서 확인할 수 있음

댓글과 토론

Hacker News 의견들
  • 전직 V8 엔지니어 관점에서 보면 SunSpider는 형편없는 벤치마크이고, 아직도 추적한다는 게 믿기 어려움
    지난 15년 가까이 JavaScript 성능 엔지니어링 방향을 잘못 이끌었고, 실제 사이트에는 도움이 안 되는 이상한 최적화 꼼수를 엔진들에 만들게 했음
    V8은 오래전에 대부분의 마이크로벤치마크에서 벗어났음: https://benediktmeurer.de/2016/12/16/the-truth-about-traditi...
    그렇다고 Firefox의 성능 개선이 중요하지 않거나 반갑지 않다는 뜻은 아님. 다만 SunSpider는 볼 수 있는 벤치마크 중 최악이라는 뜻임

    • 정확히 말하면, 오래된 대시보드 일부로 아직 돌리고 있다는 의미에서 추적하고 있음
      비용이 낮고, 가끔 의도치 않은 성능 회귀를 잡아주기도 함
      SpiderMonkey 팀도 마이크로벤치마크를 무시하는 데 전적으로 동의함. 현실 성능과 꽤 잘 상관되는 Speedometer를 중요하게 보고, JetStream2는 필요한 일부만 골라 봄
      그보다 오래된 건 목표가 아니라 측정 막대일 뿐이라, 수치가 올라가면 좋지만 다른 이유로 하는 작업의 부수 효과일 때만 그렇게 됨
      특히 이 그래프의 SunSpider 개선은 올해 해온 Speedometer 작업의 부수 효과임
    • 올린 링크는 Speedometer를 밀고 있는데, 거기서는 Firefox가 이미 Chrome을 앞질렀다고 알려져 있음
      https://news.ycombinator.com/item?id=36770883
    • Firefox는 여러 벤치마크에서 성능을 추적함
      지난 1년간 여러 항목에서 Chrome 대비 성능을 보면, 상당수에서 꾸준한 개선이 이어지는 점이 고무적임
      https://arewefastyet.com/win10/benchmarks/overview?numDays=3...
    • 실제 사이트 기반 벤치마크는 좋은 생각이면서도 나쁜 생각처럼 보임
      좋은 이유는 obvious하지만, 나쁜 이유는 피드백 루프를 만들기 때문임. 사람들은 성능에 맞춰 개발하고, 성능은 사람들이 개발한 것에 맞춰 개선됨
      V8 팀에서 이런 문제를 어떤 식으로 다뤘는지 궁금함
    • 공평하게 보면 SunSpider가 처음 나왔을 때는 당시 웹에 존재하던 JavaScript 엔진의 핵심 병목을 꽤 정확히 반영했음
      V8에도 해당됐고, V8이 출시 때 자체 벤치마크 묶음을 내놓긴 했지만 속성 접근에 과하게 치우쳤고 SunSpider가 우연히 다루던 초기 페이지 로드 쪽은 부족했음
      물론 그게 15년 전 일이라, 당시 벤치마크가 지금 유용한 무언가를 반영한다고 보긴 어렵고 이제는 거의 회귀 감지 외에는 가치가 크지 않음
  • 내가 가진 모든 컴퓨터와 휴대폰에서는 Firefox만 씀
    지금까지 성능에 매우 만족하고 계속 개선되길 진심으로 바람. Firefox를 쓸 수 없을 때의 두 번째 선택지는 Brave이고, Chromium은 가장 마지막 선택지임
    Firefox에서는 이 확장들을 강력 추천함: AdNauseam https://addons.mozilla.org/en-US/firefox/addon/adnauseam/, Consent-O-Matic https://addons.mozilla.org/en-US/firefox/addon/consent-o-mat..., Firefox Multi-Account containers https://addons.mozilla.org/en-US/firefox/addon/multi-account..., I don't care about cookies https://addons.mozilla.org/en-US/firefox/addon/i-dont-care-a...
    아래에서 나온 것처럼 Avast를 신뢰하지 않는다면 Consent-O-Matic은 피하는 게 좋음

  • “Firefox가 10년 된 JavaScript 벤치마크에서 Chrome을 쉽게 이긴다”와 동시에 “더 새롭고 더 까다로운 JetStream 2.0에서는 Google Chrome이 Firefox를 여전히 쉽게 이긴다”는 얘기임

    • macOS에서는 Safari가 Chrome을 그보다 더 큰 차이로 압도함
    • Firefox를 매우 좋아하지만 이걸 읽으니 좀 씁쓸함
  • SunSpider는 2013년 이후 업데이트되지 않았다는 점을 짚을 필요가 있음
    JetStream이 현대 JavaScript 작업 부하를 더 잘 대표하지만, 그 벤치마크에서도 격차가 줄어드는 중임

  • V8 엔진으로 작업 중인데, 예상 못 한 것들이 느려지는 탈최적화 지뢰밭
    예외 처리기 구조가 코드의 성능 특성을 크게 바꿀 수 있고, async/await는 정말 운에 가까움. 어떤 때는 Promise가 더 빠르고, 어떤 때는 async 블록이 더 빠름
    일부 느려짐은 빈약한 명세 탓으로 돌릴 수 있음. 왜 ... 구조 분해가 반복자를 쓰는지 모르겠음
    하지만 V8 팀이 완벽하게 작성되지 않은 현실 코드보다 벤치마크를 좇는 건 아닌지 궁금함

    • ...가 반복자를 쓰지 못한다면, 특히 제너레이터의 힘이 훨씬 약해질 것임
    • V8 팀은 그렇게 하지 않음
      이 벤치마크에서 V8 성능이 정체된 건 오래전부터 신경 쓰지 않았기 때문임
      Firefox는 아쉽게도 신경 쓸 유인이 있음. 벤치마크가 중요하지 않더라도 뒤처져 보이면 여전히 나빠 보이기 때문임
    • 오히려 반대 아닌가? https://v8.dev/blog/real-world-performance
      이 주제를 수치와 예시로 다룬 더 최근 글이 있었던 것 같은데 지금은 못 찾겠음. chromium/chrome 팀 블로그였을 수도 있고, 다른 사람이 찾을 수 있을지도 모름
  • 최근 Chrome이 악해지고 있다는 얘기가 많아서, 내 Chrome 확장인 IPvFoo를 Firefox에서도 제대로 동작하도록 며칠 다듬었음
    IPvFoo는 IPv6 전환을 관찰하는 도구임. 기술적으로는 2017년부터 Firefox용도 있었지만, Firefox가 언젠가 고쳐주길 바라던 호환성 버그가 많았음
    결국 남은 문제들을 우회하기로 했고, 이제 공통 코드베이스에서 Chrome/Firefox 기능 동등성이 맞춰짐: https://github.com/pmarks-net/ipvfoo

  • uBO를 켠 Firefox는 Chromium 기반 브라우저보다 100% 이상 빠름
    Chromium 기반 브라우저에서는 제약 때문에 uBO가 제대로 동작하지 않음

  • 개선은 실제임
    아직 출시 전이지만 오픈소스인 최신 Speedometer 3.0으로 방금 테스트했고, 각 브라우저의 최신 버전을 사용했음
    Firefox Nightly(Gecko) 11.6, Safari TP(WebKit) 11.4, Chrome Canary(Blink) 9.9
    https://github.com/WebKit/Speedometer

  • 솔직히 나한테 Firefox는 디버깅 도구가 Chrome 수준이 되고 탭 UI를 조금 더 다듬기 전까지는 두 번째 선택지임
    매일 Firefox를 쓰고 싶지만, 쓰면 개발 속도가 떨어진다는 느낌이 듦

    • 나는 오히려 Firefox의 개발자 도구가 훨씬 다루기 쉽다고 느낌
      Firefox 디자인은 마음에 들지 않지만, 테마와 애드온으로 고칠 수 있음
    • UI가 문제라면 userchrome.css를 조금 손봐보면 됨
      나는 treestyletab을 원하는 방식으로 쓰려고 그렇게 했고, UI에 신경 쓴다면 userchrome.css가 꽤 많은 자유를 줌
      게다가 Nextcloud로 기기 간 동기화해 둬서 기기마다 따로 바꿀 필요가 없음
    • 나도 비슷하게 UI가 조금 바뀌었으면 좋겠음
      화려할 필요는 없고, 기본 Chromium처럼 단순한 정도면 괜찮겠음
  • 최근 Firefox 성능 회귀를 보고 버그 리포트를 내려고 살펴봤는데, 성능을 꽤 공개적으로 추적하는 도구들이 관심을 받는 듯함
    추적 프로파일을 쉽게 업로드해 공유할 수 있는 것도 도움이 됨: https://firefox-source-docs.mozilla.org/testing/perfdocs/ind...
    Firefox 성능에 관심이 있다면 전용 블로그가 계속 소식을 알려줌: https://blog.mozilla.org/performance/
    특정 웹사이트에서 Chromium이 눈에 띄게 더 빠르다고 느낀다면 간단한 신고에는 https://webcompat.com/가 있음. 다만 GitHub Issues에 익숙한 입장에서 봐도 Bugzilla가 생각보다 괜찮음