Con la reciente salida de Internet Explorer 8 hemos asistido al nacimiento del segundo gran navegador multiproceso después de Chrome. ¿Qué significa esto? ¿Este tipo de navegadores son el futuro? ¿Qué ventajas e inconvenientes tienen respecto a los navegadores con un único proceso? Y lo más importante: ¿nos beneficia o nos perjudica a los usuarios este cambio de paradigma? Estas preguntas y algunas más las intentaré contestar en esta entrada.
<h3>¿Qué son los <em>navegadores multiproceso</em>?</h3>
Normalmente, cada aplicación ejecuta un único proceso, desde el cuál controlará todas las acciones que tenga que realizar. Si necesita hacer varias cosas a la vez, creará varios hilos, que no son más que subprocesos ligeros que comparten casi todos los datos o casi todas las instrucciones. De esta manera los recursos se utilizan de manera más eficiente, sobre todo la memoria, ya que al compartirla se evita tener que guardar varias veces lo mismo.
Comenzando una analogía que no sé si me va a gustar, un navegador monoproceso sería una empresa convencional, y los hilos serían sus trabajadores, que efectivamente pueden trabajar en paralelo y tienen aproximadamente la misma información, la que les provee la empresa. Este modelo es el que tradicionalmente han seguido las empresas pequeñas, y no les ha ido mal.
En contraposición, los navegadores multiproceso, como su propio nombre indica, crean varios procesos para realizar esas mismas tareas. En este caso suelen crear un proceso por cada página o pestaña que abramos (luego lo matizaré). En principio esto no tendría demasiado sentido, ya que un montón de memoria se repetirá, como por ejemplo las instrucciones que procesan el HTML o el motor de Javascript. Sin embargo, se obtienen mejores resultados al tratarse de un programa que tiene que estar preparado para ejecutarse durante horas o días seguidos.
Siguiendo y terminando con la analogía anterior, un navegador multiproceso es una gran empresa que trabaja en diferentes regiones. Aunque se dedica a hacer lo mismo en una región que en otra, una rama ciertamente no necesita saber nada sobre los clientes de otra rama. De esta manera necesitamos dirigentes o ingenieros “repetidos” para llevar cada una de las ramas, coste que nos ahorraríamos si solo tuviéramos una gran fábrica. A pesar de todo este modelo funciona bastante bien, y entre otros aspectos resalta uno interesante: si una rama tiene problemas no afecta a las demás.
<h3>¿Qué ventajas/desventajas tienen?</h3>
Lo más obvio es que se necesitan más recursos para ejecutar lo mismo que en navegadores monoproceso, ya que como he comentado antes muchos datos se guardan varias veces en memoria. Esto es algo malo de por sí, pero no creo que sea algo excesivamente notable con la cantidad de memoria que tenemos hoy en día.
De hecho, tras un tiempo usando el navegador abriendo y cerrando pestañas, el uso de memoria será incluso más eficiente que un navegador convencional. Esto es debido a que, cuando cerramos una pestaña, automáticamente se destruirá el proceso y los huecos que se liberan se administrarán desde rutinas específicas de nuestro Sistema Operativo. En un navegador monoproceso será el propio navegador el que tenga que ver qué hace con esa memoria, y no el SO. Por muy bueno que sea un navegador, el SO siempre será más eficiente, simplemente porque dispone de más herramientas. Esta es una de la razones por la que por ejemplo Firefox al cabo de un tiempo use más memoria que al principio aunque cerremos todas las pestañas, lo que lo hace bastante degradable.
Dejando de lado la eficiencia, la mayor ventaja de estos navegadores es la seguridad que ofrecen. Al aislar cada web en su propio proceso, es casi imposible que pueda afectar a las demás webs que están visualizando. En realidad incluso están aisladas respecto al navegador. Esto supone una funcionalidad interesantísima: si una de estas webs causa un fallo crítico que obliga a cerrarla, el navegador y las demás pestañas seguirán intactos. Es decir, si una web se cuelga, el navegador puede seguir adelante. Tradicionalmente, si una de las pestañas causa un fallo, todo el navegador se cierra inesperadamente.
Pero evitar que el navegador se rompa solo es un pequeño avance comparado con la seguridad que esta arquitectura puede ofrecer. Que dos webs estén completamente aisladas respecto a sí mismas y respecto al SO significa que es mucho más difícil infectarse con software malicioso. Y no solo en teoría, también se está probando en la práctica: Chrome ha sido el único navegador sobre el que no se ha encontrado ningún exploit en PWN2OWN, un concurso con expertos en seguridad celebrado esta semana. De acuerdo, IE8 ha sucumbido, pero eso es otro tema.
<h3>¿Cuántos procesos se crean?</h3>
Aunque las arquitecturas de Chrome e IE8 tienen algunas diferencias, las dos crean un proceso inicial que será el que se ocupe de la interfaz (las ventanas, las barras, etc), de todas las comunicaciones con el sistema (entrada/salida de ficheros, de internet, etc) y con el usuario (teclado, ratón, pantalla). Este es el proceso padre, y si se cierra se cerrarán todos los demás.
A partir de entonces se crean procesos adicionales por una o más webs que abramos. Cada proceso contendrá los motores de renderizado de HTML, CSS, Javascript, imágenes, etc necesarios para leer una página web. Esta es la información que se repetirá tantas veces como procesos tengamos abiertos. Estos procesos están aislados del resto del sistema, y solo se comunican con el proceso padre: si quieren acceso a disco lo tienen que hacer a través del padre, si quieren acceso a la red o a la pantalla también.
Aquí está la diferencia entre IE8 y Chrome, ya que los dos crean procesos de manera distinta. IE8 calculará cuántos procesos debe abrir dependiendo del número de sitios web que abras: si tienes cinco sitios abre 3 procesos, si tienes 15 abre 6, los que sean. Cada proceso se ocupará de varios sitios webs por defecto, y si uno de esos sitios web causa un fallo, los demás sitios que maneje ese proceso se cerrarán también. En cierto modo es como si balanceara la carga de varios sitios web entre varios procesos, tal y como se hace en un servidor web. Una manera rápida de ver los sitios que comparten un mismo proceso es ver qué pestañas comparten el mismo color (aunque si tienen distinto color también pueden compartir proceso).
Chrome sigue una arquitectura que me parece que tiene algo más sentido. En principio crea un proceso por cada sitio web que abras. Si abres otra pestaña con el mismo sitio web (por ejemplo, dos artículos de Genbeta) será lo suficientemente inteligente para reutilizar ese proceso. Este algoritmo seguirá repitiéndose hasta llegar a un tope que actualmente se acerca a los 20 procesos, a partir de este punto varias webs compartirán procesos de manera similar a IE8.
Otro punto fundamental de Chrome es que también aísla en su propio proceso a los plugins, cosa que IE8 no parece hacer. Estos componentes externos a los navegadores son probablemente la parte más inestable y la parte menos segura, así que es una buena idea aislarla también.
<h3>¿Es este el futuro?</h3>
Sí. Los navegadores tradicionales tienen sentido en la web tradicional, con sitios simples y recursos muy limitados. Hoy en día tenemos varios factores que nos llevan a preferir una arquitectura multiproceso: las aplicaciones web son tan complejas como las de escritorio (piensa en Gmail, Google Docs, etc), los navegadores se utilizan durante mucho tiempo, gracias a las pestañas cada vez abrimos más webs a la vez y la cantidad de memoria RAM es bastante grande. Y ni siquiera he hablado de los procesadores multinúcleo: un navegador multiproceso puede aprovecharlos más que los actuales multihilo, y si cada vez tenemos más núcleos habrá que explotarlos más.
Por estos motivos creo, espero y quiero que Firefox, Opera y Safari implementen esta arquitectura cuanto antes. Cualquiera que haya probado Chrome (en menor medida IE8) habrá comprobado que la experiencia de usuario es mucho mejor a lo que estamos acostumbrados, y que la estabilidad general del navegador es muy alta aunque visitemos sitios pesados. En general, todo se reduce a que los navegadores multiproceso no se degradan con la misma facilidad que los tradicionales.
Enlace | Arquitectura de Chrome
Enlace | Chrome en Pwn2Own
Enlace | LCIE en IE8
Enlace | Arquitectura de IE8
Enlace | Procesos en IE8 y Chrome
En Genbeta | Google Chrome
En Genbeta | Internet Explorer 8
Ver 30 comentarios
30 comentarios
Lord Darkness
Bueno el artículo está muy bien, pero hay que matizar algunas correcciones y agregar algunos datos:
-Otra diferencia de IE8 y Chrome es arquitectónica. IE crea dos procesos inicialmente, uno para pestañas y otro para interface. Chrome NO. Un proceso para cada pestaña siendo la interface un fork para cada proceso de pestaña.
-Los procesos consumen más memoria (como tu bien haz dicho) pues crean espacios de memoria propios. Pero hay mas gasto de recursos que eso: A) la comunicación entre procesos es mas "onerosa" que con hilos B) El cambio de contexto para intercambiar procesos produce overhead C) se debe manejar mejor la rutina de programación poniendo semáfaros para que no haya "choques" entre procesos (john carkmark lo hay dicho, programar multriproceso es tremendamente difícil) D) se tarda más en crear un proceso que un hilo E) los procesos necesitan al kernel para la comunicación los hilos NO Los hilos son mas económicos SIEMPRE, en sistemas operativos de escritorio (Lease NT, Linux, etc)
Es por ese motivo que Chrome consume mas recursos que su competencia y el cambio de ventanas es más lento ;) (a pesar de su buen render de javascript, interfaz poco recargada y carencia de funciones avanzadas)
Y es por eso también que hay navegadores monoproceso más rapidos, avanzados y livianos que Chrome (no pongo a IE pues crea menos procesos)
Saludos
PD: matizar que no tiene nada que ver la capacidad multiproceso de los micros modernos con el multiproceso en programación (esta se puede hacer con un solo micro) y multihilos por hard hay desde el hypertreading del P4...
Víctor Pimentel
Lord Darkness: Sí, es cierto. Por un lado se necesita cargar más datos en memoria, así que el inicio es teóricamente más lento tanto al iniciar la aplicación como al crear una nueva pestaña. También la comunicación entre procesos es mucho más costosa que entre hilos.
Peeeero aún así hace falta mirarlo desde otro ángulo. ¿Por qué? Porque todo lo que has dicho lo miras desde la perspectiva de que un navegador es una aplicación. Los chicos de Google lo han mirado desde la perspectiva de que tienen una especie de Sistema Operativo Virtual (el proceso padre) y luego varias aplicaciones (los procesos hijos). No quería decirlo, pero en cierto sentido es como Java, pero más limitado.
Aunque pueda parecer una burrada, tiene sentido con lo que vemos hoy en día en la web. ¿Cuántos megas de memoria puede solicitar una web como Google Reader? ¿Cuánto procesador puede requerir un servicio como Gmail? Mira el consumo de recursos de tu navegador: probablemente sea la aplicación que más esté consumiendo (memoria, cpu, red).
Mi teoría es que llegado este punto en el que las aplicaciones web son tan pesadas, hay ciertas tareas que merece la pena delegar en el SO. Aunque eso implique tener que complicarse la vida con tuberías "nombradas" como hace Chrome. Piensa que de esta manera, el navegador no tiene que preocuparse de cómo se maneja la memoria o qué pestaña recibe más CPU, ya que deja que el SO trabaje.
Miento, Chrome también se preocupa en ese aspecto, y le asigna más prioridad a la pestaña que está enfrente. Es más, si minimizamos su ventana, entonces bajará la prioridad a todas sus pestañas. ¿Sabes lo difícil que hubiera sido implementar eso tan sencillo sin procesos?
Los hechos están ahí: Chrome funciona, es probablemente el más rápido y a largo plazo apenas se degrada. Además, tiene un par de suculentas características derivadas de que todo se ejecute en un sandbox, como la seguridad. Y p
vaya torzon que llevo
No creo que todo sea tan simple que decir que porque sean varios procesos vaya a estar bien optimizado para procesadores multicore, no entiendo mucho de ello pero me imagino que la ejecución de cada core en cada proceso dependa más del SO que del programa en sí, con lo que es funcionará igual de mal o bien en Vista o XP, que tienen una capacidad de gestión más bien nula (bueno XP es nula nula)
No sabría decir exactamente, pero no noto ningún tipo de mejora en Chrome teniendo un Q6700 (Quad Core) respecto de Firefox o similares ... siendo realista, Opera va bien, porque es un navegador de puta madre y porque está increíblemente optimizado, el resto pueden ir mejor o peor, pero no creo que el que tenga uno o varios procesos sea demasiado determinante ... es mi opinión claro
Lord Darkness
Como anexo te dejo mis propias pruebas de rendimiento y recalcando que es un alpha contra una versión final, todo testeado en Server 2003 + process Explorer para ver los detalles técnicos de consumo y demas:
=======================================================
Google Chrome 1.0.154.48 (motor webkit)
Tiempo inicio en frio: (4"18) carga youtube: 6"42 (33256 KB + 31125 Kb ) carga msn: 15"30 (56712 KB + 40620 KB) carga blogger: 9”74 (76760 KB + 54720 KB) carga yahoo: 16"16 (101904 KB + 73568 KB)
ACID 3: 78/100
Web Browser Javascript Benchmark: 416 ms =======================================================
Opera 10.00 (1355) (Motor Presto)
Tiempo inicio en frio: (4"02) carga youtube: 7"29 (41568 KB + 37876 KB) carga msn: 11"81 (59148 KB + 55500 KB) carga blogger: 9'26 (64500 KB + 61600 KB) carga yahoo: 13"88 (81956 KB + 79048 KB )
ACID 3: 100/100
Web Browser Javascript Benchmark: 531 ms =======================================================
El consumo de memoria está en formato (xxxxx + xxxxx) que quiere decir consumo de memoria física + memoria virtual. Fíjate que al principio es razonable el consumo de memoria, pero en cuanto se apilan los tabs se disparan (esto pasa por tener espacio de memoria para cada proceso, llamadas de api duplicadas y esas virguerías técnicas) Y otra cosa que no matiza el benchmark es la sensación de respuesta y el consumo de CPU, que en ambos casos es inferior en Opera… Chrome se destaca en javascript (hasta que llegue Carakan? ) y carga youtube un poco más rápido (faltaba más es de Google :P…nah mentira Opera le falta rapidez al cargar el plugin Flash Player si bien ha mejorado últimamente)
Saludos
Kandomble
@Víctor Pimentel felicidades es tu post 666 xD
Lord Darkness
@Víctor Pimentel: ante todo buen debate ;) Si es verdad lo de la complejidad de los recursos web y demás (cosa que la verdad no termino de justificar, pronto van a consumir más que un videojuego :P ). Si lo pienso como “sistema operativo virtual” pues justamente que delegan demasiadas cosas al sistema operativo (con lo complejo que son hoy en día) y en cierta forma también es “recargarlo” un poco. Por algo Microsoft se quedó a mitad de camino del multiproceso ;) y debemos suponer que miraron como funciona Chrome y sacaron sus propias conclusiones. Luego te lo voy a poner desde el punto de vista del usuario. Es demasiado consumo de memoria, con 6 tabs se puede ir a 120 MB como si nada (sin contar los plugins y demás) y ahora debo nombrar a la competencia. Fijate Firefox. Ya solucionaron la fuga de ram, así que consume mucho menos. Y es rápido, estable y renderiza correctamente. Y el ejemplo clave es Opera. Es más liviano que Chrome y tiene muchísima más funcionalidad que el mismo. Y siendo Monoproceso. Hay una cuenta que no cierra :P para decirlo prosaicamente…. Técnicamente esta muy bien programado Opera. No crea tampoco tantos threads, pero puede leer correo, bajar bittorrent, abrir muchas pestañas, etc, etc y sin consumir tanta memoria RAM. Tampoco ralentiza el operativo, y es muy estable. Entonces…donde está la ganancia en el multiproceso? Fíjate IE8. Al abrir tarda en mostrar la primera pestaña (proceso separado de la interface), cosa que no pasa en los demás. Ahí le doy la derecha a Chrome, es mejor un proceso y varios fork a las tabs que usar dos sacos distintos para interface y tabs.
Sigue =>
silver
"Entonces…donde está la ganancia en el multiproceso? "
Claramente no en el consumo de RAM, como ya lo dijeron antes, pero con el hardware de hoy no es algo tan drástico.
La ganancia está en que al ser procesos diferentes se pueden terminar solo el que falla, no todos. Como ocurre con los demás. Y Ópera 10 no es tan estable como dice ser, al menos a mí se me ha colgado varias veces justamente al abrir 12 o 13 pestañas.
Ya por otro lado pasa el motor, que lo veo verdaderamente rápido a webkit, cuestiones estéticas, etc.
Víctor Pimentel
Gracias Kandomble por darte cuenta de que es el 666 xD Y a los demás por la felicitación.
Supongo que en Mozilla y Opera estarán pensando a ver cómo lo hacen, porque las mejoras son muy interesantes... Apple con Safari supongo que también, porque ya tienen el camino prácticamente hecho al estar basado en el mismo motor de Chrome.
Por cierto, también espero que alguien cambie su motor por Webkit, realmente es increíble la velocidad y eficiencia que han conseguido con ese motor, por no hablar de los estándares. Si al menos IE utilizara Webkit los desarrolladores web podríamos respirar tranquilos de una vez por todas :)
Alexuny
Pues será multiproceso, pero probé antes d eayer a actualizar a IE8 y sigue siendo la misma castaña que antes.
Chrome es bastante más ágil y rápido. Y sin ser multiproceso, en mi caso al menos el que mejor rinde sin lugar a dudas es Opera.
david
Muy buena explicacion. Espero que IE se ponga al día muy pronto. Ultimamente estoy probando la experiencias con varios navegadores y en relidad el opera y el chrome estaba muy bien parados. Estos modelos multiprocesos son muy buena idea varias veces se me ha cerrado el opera con varias tabs abiertas, aunque cuando lo abro me dice que si deseo restaurar las paginas...pero no es lo mismo....
jayjayjay_92
Kandomble Pecadorl!
@energy52 donde leiste que firefox 4 iba a ser multiproceso, decian algo mas de lo que va a llevar firefox 4 o solo eso?
@8 Si, webkit es lo mejor, actualmente QT es lo mejor de lo mejor y eso que en linux uso gnome.
Malqpor
Excelentísimo artículo, muy aclaratorio.
La verdad es que podemos esperar sentados a que Opera y Firefox sean multiproceso, porque las versiones que actualmente están en desarrollo (10 y 3.5 respectivamente) no lo traen, por lo cual tocará esperar a posteriores versiones, un año le hecho yo como poco xD.
Aún así sobreviviremos, no ser multiproceso no los hace peores navegadores, solo mas ineficientes e inestables xD.
Saludos
PD: ¿En que "pensaban" los analistas de Microsoft al escoger esa arquitectura multiproceso?
Malqpor
El multiproceso en programación mono-núcleo se llama multiplexado ¿no?.
Además para multinúcleo se puede programar (que yo sepa), pasando de semarotos. De una forma parecida a dividir un proceso en dos hilos, pero haciendolo en dos procesos, sin que estos se den de hostias entre sí.
Aclarar que no estoy rebatiendo nada, es pura curiosidad. Esta parte de la programación esta un poquito por encima de mi nivel.
Saludos
PD: John Carmack es dios
jayjayjay_92
@12 energy52 Gracias por el articulo, los periodistas son lo peor despues de los banqueros y judios
Malqpor
A ver, el ser multiproceso o monoproceso no define necesariamente a un navegador; ser multiproceso es un pro orientado a los equipos con alta capacidad de recursos (cualquiera mínimamente actual).
Pero no le deis vueltas a la cabeza, ni Opera ni Firefox se han vuelto peores de repente por no ser multiproceso, esto solo manifiesta que son mejorables.
@Silver. Opera 10 es un alpha, no debería ser estable.
Saludos
jayjayjay_92
Ostias lo que he puesto! @12 energy52 Gracias por el articulo, los periodistas son lo peor despues de los banqueros y judios queria poner y banqueros pero estaba escuchando i need a jew de padre de familia XDDD vaya metedura de pata
PD:family guy uber alles
jayjayjay_92
Esto, era y politicos no y banqueros, eso lo dije antes :P
Kandomble
Excelente explicación muy completa, solo con una salvedad la obviedad que ocupa necesita más recursos no es tan lógica, y dependerá del numero de acciones, y el objeto de las mismas a realizar. ahora bien, si son el futuro, basta mirar que dos principios estan en contraposición eficiencia por eficacia, creo que solo dependerá de los usuarios considerar que prefieren y el rendimiento lo veremos por el camino
Geek
Confío en que Opera será multiproceso muy pronto... Me encanta este metodo ya que muchas veces tengo más de 15 pestañas abiertas en el Opera y si una es muy pero muy pesada, todas se ven algo lento, aunque por lo general no me molesta. El problema me viene a la cabeza si una se esas pestañas se colgara, y en algunas otras estuviese escribiendo algo importante, pocas veces me ha pasado y la mayoría opera recupera las páginas con lo escrito. Pero creo que el rendimiento del navegador mejoraría. Opera y FF estan atrasados en este punto, ojalá pronto cambien...
Manuel de la Fuente
Lindo post apocalíptico. :)
Es cierto lo de la estabilidad de Chrome; aunque parezca extraño, en ocasiones me harta que no cause problemas (tantos años de usar Firefox) y trato de forzarlo con webs pesadas... pero no, no se cae. :P
Aunque cuando estaba en beta sí se me colapsaba muchas veces, y nunca fue sólo una pestaña, sino todo el navegador. Personalmente, eso de que aísla los problemas en cada pestaña siempre se me quedó sólo en teoría.
Y comparto tu opinión respecto a WebKit, también a mí me sorprende lo eficiente que es, tanto en velocidad, estabilidad, renderización, compatibilidad... ¿en qué no sale ganando?
Toni M
Excelente análisis, Víctor. Un post de 10.
alexito4
Increible e interesantisimo post! El post lo he entendido a la perfección. Los comentarios, me he perdido en alguno xD Hablaís de cosas de programación un tanto (mucho) por encima de mi nivel, pero mola xD
Gracias por estos post;)
Víctor Pimentel
Lord Darkness: No quiero defender a Chrome, pero deberías comparar la versión 2.0 "beta" con Opera 10 alpha :P
Aún así, comprendo y entiendo que Chrome consuma más memoria que los demás. Pero es que hay que ir olvidándose del pasado, y ahora 200MB de RAM no son la burrada que eran hace 5 años. Ahora eso es la décima parte de lo que lleva el PC más barato que se está vendiendo...
Repito que lo de la fragmentación de memoria es algo bueno en este caso. En un navegador monoproceso iremos acumulando memoria en un único proceso, pon que tras 20 pestañas abiertas tienes 200MB. En uno multiproceso pon que esas mismas 20 pestañas tienen procesos de 15MB, con lo que tienes 15x20=300MB. ¿Te merece la pena gastar 100MB más por mejorar la seguridad y la estabilidad del navegador? Si tienes 4Gb, ¿seguro que los estás usando todos? La RAM, mientras más se use, mejor. Y si dejas que el sistema trabaje con pedacitos de ella en vez de tener que tratar con un bloque compacto de cientos de gigas, mucho mejor.
Dices que Opera es ya bastante estable, y no lo dudo. Pero si se rompe por cualquier motivo (y todos los navegadores terminan haciéndolo), tienes que reiniciar el navegador completo. Estaremos de acuerdo que eso es muy difícil que pasa en Chrome ;)
En realidad, yo estaría contento con que aislaran de una vez por todas a los plugins en su propio proceso. Estoy harto de que Flash se vaya a la mierda y se lleve al navegador de por medio.
Manuel de la Fuente
A ver, vengo aquí a molestarlos con mi ignorancia, y he de decir que, sin hacer pruebas ni nada, he visto que Google Chrome arranca al instante, tanto o más rápido que Opera, y puedo tenerlo abierto hasta con 20 pestañas (no me he visto en la necesidad de abrir más) sin sufrir ni la más mínima ralentización de mi máquina (1 GB de RAM en Windows Vista); y su estabilidad ya la mencioné más arriba. ¿Que si estoy a favor del multiproceso? Claro que sí.
energy52
Un artículo muy bueno, felicidades. Tengo entendido que Firefox 4 también será multiproceso. Lo cierto es que yo también estoy de acuerdo en que este tipo de navegadores serán el futuro, a pesar del mayor consumo de recursos que pueda suponer.
Con FF3 muy pocas veces fallan las páginas hasta el punto de que tengas que cerrar el navegador, pero recuerdo que con FF2 esto era algo relativamente frecuente. Lo peor es que al intentar abrir de nuevo el navegador, cargaba de nuevo las mismas pestañas y evidentemente volvía a petar, creándose así un bucle del que era difícil salir.
bEx
Espero que Opera pronto ocupe los multiprocesos. Es el navegador que uso y me parece muy bueno y personalmente mas ameno y rapido almenos que FireFox.
Daniel Aréchiga
Excelente explicación, yo sabía de esto de multiprocesos en Chrome e IE8, pero no tenía idea de los criterios que seguían. También creo que es el futuro, tiene más ventajas que problemas.
deadfunk
muy buen post, y completamente deacuerdo
energy52
@10 jayjayjay_92: Lo leí en este artículo de El País. Según cuentan, el presidente de Mozilla ha dicho que "el próximo Firefox" también será así, como Chrome, así que supongo que se referirá al 4, no creo que una mejora así de gorda la metan en el 3.5. Eso sí, la periodista mete la pata bastante diciendo que tratar cada pestaña como un proceso independiente permite ahorrar recursos xDDDD.
Es curioso que habiendo consultado en un montón de blogs sobre estos temas en ninguno se mencione nada al respecto y que en cambio en un medio no especializado como este periódico sí que aporte esta información.
Editores de Genbeta, ya sabéis, no estaría mal un artículo al canto xD.
silver
Es una muy buena explicación y comparación.
Y me quedo con esto: "Si al menos IE utilizara Webkit los desarrolladores web podríamos respirar tranquilos de una vez por todas :)"
Victor tiene la posta :)
_________________________
@Lord Darkness: "Es por ese motivo que Chrome consume mas recursos que su competencia y el cambio de ventanas es más lento ;) (a pesar de su buen render de javascript, interfaz poco recargada y carencia de funciones avanzadas)"
para mí el cambio de ventana en chrome es el doble de rápido que los otros navegadores. Y lo de la interfaz poco recargada, no sólo eso, sino también que es minimalista, dentro de todo bonita y te permite visualizar mas la web ya que no tiene un montón de barras molestando