1 puntos por GN⁺ 2023-08-16 | 1 comentarios | Compartir por WhatsApp
  • Firefox se volvió más rápido que Chrome en el antiguo benchmark de JavaScript SunSpider, pero esta prueba ya fue reemplazada en gran medida por JetStream
  • Firefox Nightly News informó recientemente que Firefox aparentemente está superando a Chrome en SunSpider, y las cifras públicas también muestran ventaja para Firefox
  • La fuente del benchmark es AreWeFastYet.com, y la comparación se basa en una prueba de rendimiento de JavaScript de hace unos 10 años
  • En el benchmark más reciente y exigente JetStream 2.0, Google Chrome sigue superando con facilidad a Firefox
  • Durante el último mes aproximadamente, Firefox también ha avanzado en varias mejoras además de la velocidad de ejecución de SunSpider, como la velocidad de subida en HTTP/2

Ventaja de Firefox confirmada en el viejo SunSpider

  • Los desarrolladores de Mozilla ven de forma positiva que Firefox haya obtenido resultados más rápidos en el benchmark de JavaScript SunSpider que Google Chrome
  • SunSpider es un benchmark de JavaScript de hace unos 10 años y actualmente ya fue reemplazado por el benchmark JetStream
  • Recientemente, Firefox Nightly News señaló: “We’re now apparently beating Chrome on the SunSpider JavaScript benchmark!”
  • Las cifras publicadas muestran una tendencia en la que Firefox supera con claridad a Chrome en este antiguo benchmark de JavaScript
  • Los datos del benchmark provienen de AreWeFastYet.com

En los benchmarks más modernos se mantiene la ventaja de Chrome

  • En el benchmark más nuevo y más exigente JetStream 2.0, Google Chrome sigue superando con facilidad a Firefox
  • Firefox elevó significativamente durante el último mes aproximadamente la velocidad de ejecución del benchmark de JavaScript SunSpider
  • En el mismo periodo también avanzó en varios trabajos, incluyendo mejoras en la velocidad de subida de HTTP/2
  • Los cambios en las compilaciones más recientes de Firefox Nightly pueden consultarse en Firefox Nightly News

1 comentarios

 
GN⁺ 2023-08-16
Opiniones de Hacker News
  • Desde la perspectiva de un exingeniero de V8, SunSpider es un benchmark pésimo, y me cuesta creer que todavía lo sigan monitoreando.
    Durante casi los últimos 15 años orientó mal el rumbo de la ingeniería de rendimiento de JavaScript, e hizo que los motores implementaran trucos raros de optimización que no ayudan en sitios reales.
    V8 dejó atrás hace mucho la mayoría de los microbenchmarks: https://benediktmeurer.de/2016/12/16/the-truth-about-traditi...
    Eso no significa que las mejoras de rendimiento de Firefox no sean importantes o bienvenidas. Solo significa que SunSpider es de los peores benchmarks que uno puede mirar.

    • Para ser precisos, lo monitorean en el sentido de que todavía lo ejecutan como parte de algunos dashboards antiguos.
      Tiene bajo costo y, de vez en cuando, ayuda a detectar regresiones de rendimiento no intencionales.
      El equipo de SpiderMonkey también está totalmente de acuerdo en ignorar los microbenchmarks. Le dan importancia a Speedometer, que se correlaciona bastante bien con el rendimiento real, y de JetStream2 miran solo algunas partes necesarias.
      Todo lo más antiguo que eso no es un objetivo, sino apenas una vara de medición; si los números suben, mejor, pero solo cuando ocurre como efecto secundario de trabajo hecho por otros motivos.
      En particular, la mejora de SunSpider en este gráfico es un efecto secundario del trabajo en Speedometer que se hizo este año.
    • El enlace publicado impulsa Speedometer, y ahí se sabe que Firefox ya superó a Chrome.
      https://news.ycombinator.com/item?id=36770883
    • Firefox monitorea el rendimiento en varios benchmarks.
      Si se observa el rendimiento frente a Chrome en varios rubros durante el último año, es alentador ver mejoras constantes en muchos de ellos.
      https://arewefastyet.com/win10/benchmarks/overview?numDays=3...
    • Un benchmark basado en sitios reales parece una buena idea y, a la vez, una mala idea.
      La razón por la que es buena es obvious, pero la razón por la que es mala es que crea un ciclo de retroalimentación. La gente desarrolla según el rendimiento, y el rendimiento mejora según lo que desarrolla la gente.
      Me pregunto cómo habrá abordado este problema el equipo de V8.
    • Para ser justos, cuando SunSpider apareció por primera vez reflejaba con bastante precisión los cuellos de botella centrales de los motores JavaScript que existían en la web de ese momento.
      Eso también aplicaba a V8, y aunque V8 lanzó su propio conjunto de benchmarks al salir, estaba demasiado sesgado hacia el acceso a propiedades y le faltaba cubrir la carga inicial de páginas que SunSpider tocaba por casualidad.
      Claro que eso fue hace 15 años, así que es difícil decir que un benchmark de esa época refleje algo útil hoy; ahora casi no tiene mucho valor más allá de detectar regresiones.
  • Uso Firefox en todas mis computadoras y teléfonos.
    Hasta ahora estoy muy satisfecho con su rendimiento y de verdad espero que siga mejorando. Cuando no puedo usar Firefox, mi segunda opción es Brave, y Chromium es mi última opción.
    En Firefox recomiendo mucho estas extensiones: 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...
    Como se menciona más abajo, si no confías en Avast, conviene evitar Consent-O-Matic.

  • Lo que se está diciendo es, al mismo tiempo, que “Firefox vence fácilmente a Chrome en un benchmark de JavaScript de hace 10 años” y que “en el JetStream 2.0, más nuevo y más exigente, Google Chrome todavía vence fácilmente a Firefox”.

    • En macOS, Safari supera a Chrome por un margen todavía mayor.
    • Me gusta mucho Firefox, pero leer esto me deja un sabor algo amargo.
  • Hay que señalar que SunSpider no se actualiza desde 2013.
    JetStream representa mejor las cargas de trabajo modernas de JavaScript, pero la brecha también se está reduciendo en ese benchmark.

  • Estoy trabajando con el motor V8, y es un campo minado de desoptimizaciones donde cosas inesperadas se vuelven lentas.
    La estructura de los manejadores de excepciones puede cambiar mucho las características de rendimiento del código, y async/await es casi cuestión de suerte. A veces Promise es más rápido, y otras veces un bloque async es más rápido.
    Algunas ralentizaciones pueden atribuirse a especificaciones deficientes. No entiendo por qué la desestructuración con ... usa iteradores.
    Pero me pregunto si el equipo de V8 no estará persiguiendo benchmarks en lugar de código real que no está escrito de forma perfecta.

    • Si ... no pudiera usar iteradores, el poder de los generadores se vería mucho más limitado, en particular.
    • El equipo de V8 no hace eso.
      El rendimiento de V8 se estancó en este benchmark porque dejó de importarles hace mucho.
      Firefox, lamentablemente, sí tiene incentivos para prestarle atención. Aunque el benchmark no sea importante, si pareces estar atrás, igual se ve mal.
    • ¿No es más bien al revés? https://v8.dev/blog/real-world-performance
      Creo que había un artículo más reciente que trataba este tema con números y ejemplos, pero ahora no lo encuentro. Podría haber sido del blog del equipo de chromium/chrome, o quizá alguien más pueda encontrarlo.
  • Últimamente se habla mucho de que Chrome se está volviendo malvado, así que dediqué unos días a ajustar mi extensión de Chrome, IPvFoo, para que también funcione correctamente en Firefox.
    IPvFoo es una herramienta para observar la transición a IPv6. Técnicamente existía una versión para Firefox desde 2017, pero tenía muchos bugs de compatibilidad que esperaba que Firefox corrigiera algún día.
    Al final decidí esquivar los problemas restantes, y ahora hay paridad de funciones entre Chrome/Firefox desde una base de código común: https://github.com/pmarks-net/ipvfoo

  • Firefox con uBO activado es más de 100% más rápido que los navegadores basados en Chromium.
    En los navegadores basados en Chromium, uBO no funciona correctamente por las restricciones.

  • La mejora es real.
    Aunque todavía no se lanzó, acabo de probar con el Speedometer 3.0 más reciente, que es open source, y usé las versiones más nuevas de cada navegador.
    Firefox Nightly(Gecko) 11.6, Safari TP(WebKit) 11.4, Chrome Canary(Blink) 9.9
    https://github.com/WebKit/Speedometer

  • Sinceramente, para mí Firefox seguirá siendo la segunda opción hasta que sus herramientas de depuración estén al nivel de Chrome y pulan un poco más la UI de pestañas.
    Quiero usar Firefox a diario, pero cuando lo hago siento que mi velocidad de desarrollo baja.

    • Yo, en cambio, siento que las herramientas de desarrollo de Firefox son mucho más fáciles de manejar.
      No me gusta el diseño de Firefox, pero se puede arreglar con temas y add-ons.
    • Si el problema es la UI, basta con tocar un poco userchrome.css.
      Yo lo hice para usar treestyletab como quería, y si te importa la UI, userchrome.css te da bastante libertad.
      Además, lo tengo sincronizado entre dispositivos con Nextcloud, así que no necesito cambiarlo por separado en cada equipo.
    • A mí también me gustaría que la UI cambiara un poco.
      No hace falta que sea vistosa; con que sea simple como Chromium por defecto estaría bien.
  • Hace poco vi una regresión de rendimiento en Firefox y estuve revisando para enviar un reporte de bug; parece que están recibiendo atención herramientas que rastrean el rendimiento de manera bastante pública.
    También ayuda que sea fácil subir y compartir perfiles de trazas: https://firefox-source-docs.mozilla.org/testing/perfdocs/ind...
    Si te interesa el rendimiento de Firefox, el blog dedicado mantiene las novedades al día: https://blog.mozilla.org/performance/
    Si en algún sitio web en particular sientes que Chromium es notablemente más rápido, para un reporte sencillo está https://webcompat.com/. Dicho eso, incluso viniendo de alguien acostumbrado a GitHub Issues, Bugzilla me pareció mejor de lo esperado.