Mozilla retrasa Firefox 3.6 y Firefox 4.0
por : Javier Pastor: 29 Dic 2009, 11:43
Aunque se esperaba que Firefox 3.6 llegase antes de acabara 2009 parece que no será así: Mozilla Foundation ha retrasado la aparición de esta versión, pero también ha hecho lo mismo con la futura revisión a gran escala, Firefox 4.0.
Se estimaba que Firefox 3.6 llegara en diciembre de 2009, pero en el sitio web de Mozilla se indica que el objetivo de lanzamiento de Firefox 3.6 es el de tenerlo listo para el primer trimestre de 2010.
Firefox 4.0 también llegará más tarde de lo planeado, y aunque se estimaba que llegaría en 2010 ahora dicen que llegará a finales de 2010 o principios de 2011. Un año esperando por esa nueva versión -que entre otras cosas tratará cada pestaña como un proceso independiente, al igual que Chrome- es demasiado tiempo.
vINQulos
Comentarios
Si con eso consiguen que la versión que salga sea más estable, más segura, y mejor, por mi perfecto. Creo que hacen bien en hacer eso, mejor que lanzarlo precipitadamente, con fallos de seguridad y que luego lo critiquen por ello.
Pues a mí me parece mala idea que traten cada pestaña como un proceso independiente. Malas noticias. :(
Señores, lo siento mucho pero yo para eso soy como los japoneses y nórdicos. Si dicen que lo lanzan el día X pues que sea el día X y no el día Y.
Yo de momento uso chrome y me va muxo mejor que firefox y ahora q tiene extensiones mas aun
@oscar es bueno aprender a escribir, todavía no es tarde… lo del navegador es para gustos pero firefox supera chrome en muchas cosas (y entre ellas en la calidad y refinamiento de sus extensiones) y con las extensiones apropiadas en velocidad real de manejabilidad.
@nadie
Pues a mi que cada pestaña sea un proceso independiente me parece una idea excelente, y eso que ni siquiera lo notaré. Como contra-ejemplo usaré la “maravillosa” tecnología flash, flash, al menos en linux, corre en un único hilo, por lo que puede poner uno de los núcleos de tu procesador al 100% y el resto del sistema corre sin problemas sobre el núcleo/s restante/s.
Ese mismo ejemplo puede llegar a ocurrir con Firefox, puede que como único proceso sobrecargue un núcleo de tu procesador, elevando la frecuencia del micro cuando el resto de núcleos muy posiblemente estarían en reposo. Por contra, si repartimos todo el trabajo entre varios núcleos, ganamos en velocidad, si se cae uno de los hilos no afecta al resto y sería capaz de funcionar con una frecuencia nominal del procesador mucho más baja, por no decir que si uno de los hilos (pestañas) se satura, no tiene porqué afectar al rendimiento del resto.
Como dije antes, a mi no me beneficiará, ya que aún uso un procesador mononúcleo, pero se que no siempre usaré esta configuración. Lo he comprobado en varias ocasiones en diferentes ordenadores con múltiples núcleos, si reproduzco “algo” flash en mi ordenador, el SO entero se arrastra, ya que el único núcleo se centra en contentar la voracidad del dichoso flash, en el resto, van ligeros como plumas, ya que flash solo es capaz de saturar 1 y el resto de procesos se mudan a otros núcleos. No es exactamente como lo explico, pero para hacerse una idea general.
Un saludo.
@nadie, ¿ porqué ?.
Separar cada pestaña en un proceso independiente tiene grandes ventajas. La más evidente es que cualquier fallo u error en una página determinada no te tira abajo todo el navegador sino solo la página en cuestión.
Respecto a los retrasos, a mi no me molestan en absoluto. Firefox 3.5 ya me funciona muy bien, no tengo ninguna necesidad inmediata de cambiar. Así que prefiero a que saquen nuevas versiones cuando las tengan bien maduras, por mí que no se den prisa, puesto que les voy a esperar igualmente.
#Marc
A su vez crear un proceso nuevo para cada pestaña genera un excesivo aumento en el consumo de memoria, sobre todo si estás acostumbrado a navegar con muchas pestañas abiertas.
En un equipo de sobremesa puede no notarse, pero en un netbook creo que sí.
@ioseba. No tiene porqué ser necesariamente así (si acaso parece ser el efecto de una pobre implementación).
Es más, esta arquitectura puede incluso mejorar el uso de la memoria física, puesto que solo la memoria general del navegador y la referente a la pestaña activa necesitan estar en memoria física, toda la memora relativa al resto de pestañas puede ser trasladada de forma segura a un archivo de swap en disco.
@Marc: Lo que planteas me sugiere que existira un proceso (no de SO) mas que se encargue de mover contenido de memoria virtual a memoria fisica y ese proceso pudiera ser lento debido a la naturaleza de la memoria swap. Quizas la optimizacion de memoria este dado en otro nivel.
@Marc: Lo que planteas es lo que ocurre con todas las aplicaciones, mas alla de una pestaña, una ventana, un servicio, un deamon, etc.
Hay que tener en cuenta que la capacidad de gestionar los hilos de ejecucion esta limitado por el software, lo que significa que si el soft no esta diseñado para utilizar multihilo cualquier proceso puede sobrecargar el/los nucleo/s indistintamente, casi sin control.
@Sunyear, sí, yo interpreto que aparte de los hilos de las pestañas debe existir al menos un hilo más, que es el hilo general del navegador, que entre otras cosas se ocuparía de la gestión las pestañas, sus hilos y su memoria.
Respecto a la lentitud del traspaso a disco, está claro que solo es necesario hacerlo cuando el sistema se va quedando justo de memoria. Y la verdad es que no lo veo problemático, un delay de unas centésimas de segundo al cambiar de pestaña entra dentro de lo razonable y de lo que uno se espera, mucho más molestas son las demoras por swap de la paginación habitual de Windows de memoria en disco, que se disparan cuando uno menos se las espera (por ejplo. mientras estás escribiendo un texto y se te pone el reloj de arena y el ordenador se te congela durante medio segundo).
Lo que quería decir es que si un navegador multihilo consume más memoria que un navegador monohilo, esto solo puede ser porqué cada pestaña consume más memoria, por tanto la información de cada pestaña está más separada en la memoria, incluso si esto significa que hay que duplicar la misma información para distintas pestañas. O sea (a menos que yo hoy esté muy resacoso de las comidas navideñas, y se me esté escapando algo obvio), la información de cada pestaña está separada en memoria en lugar de estar junta y revuelta como en un navegador monohilo (y que por tanto la lleva a ocupar menos espacio).
Esto debería permitir poder pasar a disco la mayor parte de la memoria usada por el navegador (toda la relacionada con las pestañas no activas), con la absoluta seguridad de que no vas a ralentizar la presentación y tratamiento de la página actual, puesto que ninguna de la información traspasada a disco tiene la menor relación con ella. Cosa muy diferente a lo que ocurre con la paginación normal de memoria a disco, donde se traspasa el bloque de memoria que hace más tiempo que no se utiliza (lo cual no es ninguna garantía de que no sea precisamente el siguiente bloque de memoria que se va a intentar referenciar, y por lo que habrá que volver a restaurarlo en memoria).
¿Demasiado tiempo? Por mí que los de Mozilla se tomen su tiempo en lanzar firefox 4. Es preferible tener software estable y testeado que un software depurado y lleno de errores… ¿No lo creen?
@Marc
No es por criticar, pero tu has abierto en tu vida 5 tristes pestañas en el Chrome y has mirado cuantos megas ocupan en memoria…..???
Que si, que es muy bonito eso de que una web se te cuelga, te cargas el proceso y listos, pero no a costa de cientos de megas de memoria ram leches….!!!
@Yo, que la implementación de Google no sea eficiente en consumo de memoria no quiere decir que haya ningún handicap con la memoria inherente a la arquitectura multihilo. Solo indica un fallo en el diseño o implementación de Google.
No veo porqué una arquitectura multihilo bien implementada tiene que consumir más memoria que una monohilo. La información que deben almacenar es exactamente la misma.
¿ Quien te dice que la implementación de Firefox no será mucho mejor que la de Google ?.
Además, en el mundo de la informática, muchas cosas son bastante relativas, y el consumo de memoria es una de ellas. Es demasiado simplista evaluar exclusivamente por la memoria RAM utilizada, cuando una buena política de paginación en disco de esa memoria puede hacer que un software tengo un impacto mucho menor en el sistema y en la percepción del usuario que otro con una utilización menor de memoria aunque con una política de paginación en disco menos inteligente.
Hay que evaluar todo el sistema.
@Marc
Wikipedia:
Los hilos se distinguen de los tradicionales procesos en que los procesos son –generalmente– independientes, llevan bastante información de estados, e interactúan sólo a través de mecanismos de comunicación dados por el sistema. Por otra parte, muchos hilos generalmente comparten otros recursos de forma directa. En muchos de los sistemas operativos que dan facilidades a los hilos, es más rápido cambiar de un hilo a otro dentro del mismo proceso, que cambiar de un proceso a otro. Este fenómeno se debe a que los hilos comparten datos y espacios de direcciones, mientras que los procesos, al ser independientes, no lo hacen. Al cambiar de un proceso a otro el sistema operativo (mediante el dispatcher) genera lo que se conoce como overhead, que es tiempo desperdiciado por el procesador para realizar un cambio de contexto (context switch), en este caso pasar del estado de ejecución (running) al estado de espera (waiting) y colocar el nuevo proceso en ejecución. En los hilos, como pertenecen a un mismo proceso, al realizar un cambio de hilo el tiempo perdido es casi despreciable. Y blah blah blah…
Me da que Firefox ya es multihilo, que no multiproceso.
Google no suele hacer programas que derrochen recursos, aunque Chrome podría ser unos de ellos ya que se estarán centrando mas en funcionalidad que no en recursos consumidos. Pero intuyo que cada proceso de Chrome es como una nueva ventana del navegador por completo y lo único que cambia es la información de la web que gestiona y, por eso se merienda la memoria.
Claro que no programo ni para Google ni para Mozilla, por lo que tan solo conjeturo sobre lo que veo.
Un placer ;D
Tienes razón @yo. Estaba hablando de un sistema multihilo y no multiproceso.
Pues no me gusta la idea de que firefox sea multiproceso porque no lo necesita. Con hilos funciona muy bien. En su día se esforzaron en desarrollar una gestión de memoria bastante eficiente basándose en código de BSD y parece que dio muy buenos resultados.
Si ahora deciden hacer que cada pestaña sea un proceso independiente creo que habrían tirado abajo todo ese trabajo.
Un proceso, a diferencia de un hilo, tiene su propio espacio de memoria. Y por lo tanto es mucho menos eficiente. Más pesado. Y es el sistema operativo el que debe gestionar directamente los recursos del proceso (memoria, tiempo de ejecución, etc.).
Esto quizás tenga sentido en el caso de google si lo que pretendían era construir un “sistema operativo” sobre el navegador (el famoso googleOS basado en google Chrome): un navegador con un montón de aplicaciones web en la nube; cada aplicación una pestaña y un proceso. Sin embargo creo que los objetivos de Firefox son otros.
Para mí es mucho más eficiente, aunque seguro que más costoso de implementar, la utilización de hilos. Más costoso de implementar porque es el propio programa el que debe de gestionar los recursos de cada uno de sus hilos. No lo delega en el sistema operativo. Y esto, como ya he dicho antes, ya lo resolvieron muy bien en Mozilla con la implementación de la gestión de memoria basada en código BSD [http://barrapunto.com/article.pl?sid=08/02/20/1941218].
[...] Mozilla retrasa Firefox 3.6 y Firefox 4.0 | The Inquirer ES http://www.theinquirer.es/2009/12/29/mozilla-retrasa-firefox-36-y-firefox-40.html – view page – cached Aunque se esperaba que Firefox 3.6 llegase antes de acabara 2009 parece que no será así: Mozilla Foundation ha retrasado la aparición de esta versión, pero [...]
Publica un nuevo comentario