Benchmark do usuário: desempenho do engine javascript do Firefox 3.7 se aproxima cada vez mais do Chromium
Enviado por Bruno Tsubouchi Yporti (brunoyportiΘgmail·com):
“Realizei um benchmark da engine javascript (usando o SunSpider) do Firefox 3.6.2 e do Firefox 3.7 alpha 4, o resultado foi surpreendente: está 2x mais rápido, se aproximando cada vez mais do desempenho do Chromium (também analisado no artigo). Os comparativos detalhados estão disponíveis no artigo completo.” [referência: yporti.med.br]
• Publicado por Augusto Campos em
2010-04-07
@brlinuxblog
Feed RSS
Parece legal, mas nem só de Javascript vive uma página web dinâmica.
Tanto o Firefox quanto o Google Chrome ficam absurdamente lentos quando eu tenho umas 10 páginas com ajax e alguns banners em flash abertas.
O Javascript pode até ficar bom, mas enquanto não derem um jeito nestes plugins flash, java, .net e outras gambiarras não teremos uma web decente.
É como desenvolver um excelente motor à combustão – com toda a tecnologia que se dispõe – e depois abastecer com combustível batizado.
@Welington
A solução é bastante simples: desabilite o flash que vai funcionar bem, uma página que abusa de javascript causa menos problemas que uma página que usa um pouco de flash.
Por tal razão estou me abdicando de trabalhar com Flash em prol do jQuery que para muitos efeitos fazem semelhante a flash, exemplos:
http://www.paesonline.org.br/
http://www.narcisoenxovais.com.br/
Em ambos os sites tem efeitos com flash e efeitos com jQuery, só precisa saber quem é o quê.
Bem, javascript mais rápido. Que bom. Agora falta melhorar a renderização das coisas, pq em linux+cairo é bem mais lento que o chrome com skia :-(
Quanto ao flash, o flashblock deveria vir instalado no firefox por padrão :-)
Incrível como a concorrencia é uma coisa saudavel !
@Dyego
Até concordo com você, no caso em que há uma concorrência de verdade. Infelizmente na maior parte dos casos na sociedade atual há um monopólio disfarçado de concorrência.
Por falar em flash, saiu uma versão RC do flash 10.1 (somente para 32 bits por enquanto :-) )
http://www.guiadohardware.net/noticias/2010-04/4BBB8779.html
“Vários bugs foram corrigidos. O foco dessa versão é decodificar vídeo HD em H.264 suportando aceleração por hardware usando UVD2 (em placas da AMD/ATI) e VP2 (em placas da Nvidia), área em que o Flash Player vem recebendo destaque.”
Engraçado como a implementação do javascript era ruim nesses browsers…de uns anos pra cá, qualquer versão dá ganho de 30, 40% no desempenenho da anterior, que fazia a mesma coisa na antecessora. hehehe
Pra matar o Flash e Silverlight, além do HTML5 e CSS3 precisa vir uma versão mais poderosa do Javascript, com mais recursos. Faz anos que ele está precisando de uma reengenharia, a impressão hoje é de que ele é usado pra algo que não foi feito.
Uma coisa andei notando esses tempos o flashblock funciona melhor do que o noscript para bloquear os flashs, deveria mesmo vim por default no firefox.
@marcosalex, já estão trabalhando há anos no js2, que por sua vez é bem parecido com o action script 3.0, ambos baseados na mesma especificação ecmascript.
Mas não há adesão por parte dos desenvolvedores de navegadores. Orientação a objetos em js ainda é bem limitado. Aquele negócio de prototype é bem confuso.
Ah sim, quem “manda” na especificação do javascript é a mozilla, mas não vi até agora alguma coisa de js2 implementado em seus navegadores.
Então vamos de vbscript! hauahauah
Tem é q resolver a lentidão daquela porcaria de biblioteca de favoritos q leva anos pra adicionar ou apagar alguma coisa qdo se tem muitos itens.
Ontem a noite fiz os testes do SunSpider em 05 navegadores diferentes(Firefox-3.6.3, Google-Chrome5-dev, Opera-10.52-build-6302, Midor0.2.4git(webkit) e o Konqueror do kde 4.4.0, colocação:
1º Midori
2º Google-Chrome(build anterior ao que foi lançado com flashplayer embutido), um pouco mais lento que o Midori
3º Opera-10.52-build-6302, uma pequena diferença em relação aos dois primeiros.
4º Firefox-3.6.3, cerca de 2X mais lento que os três primeiros
5º Konqueror, cerca de 9X (41000ms) mais lento que os três primeiros.
Descupas no momentos não tenho os dados reais do teste mais as posições foram esses acima.
Não concordo que a concorrencia seja saudável .Na minha opinião a concorrencia deixa os participantes doentes ,desesperados para se manterem vivos no mercado .
Enquanto que na cooperação os participantes são livres para testar ideias diferentes sem ficar com medo de ser destruído, na concorrencia os participantes devem imitar uma qualidade do outro para se manter vivo.
Infelizmente a concorrente existe principalmente devido a necessidade .Só usamos um navegador por vez ,então precisamos de um navegador . Mas se formos escolher um navegador ,que seja aquele mais justo . E o navegador que eu considero mais justo é o firefox.
Ainda bem que não houve adesão àquele Frankstein do js2. A linguagem js de hoje é tão limpa e bonita, o js2 que estava sendo proposto pela Adobe & Mozilla ia estragar tudo introduzindo aquele monte de baboseira. É claro que a Adobe queria, pois iria deixar o js idêntico ao actionscript dela. A Mozilla parece que estava só tomando carona, pois na época haviam recebido a doação do Tamarin, que era a VM de ecmascript da Adobe, e o código rodava bem mais rápido nela usando os
“recursos” de actionscript, o que é óbvio, pois a Adobe usava essa VM no Flash.
Mas isso tudo aconteceu antes da grande guerra do js entre os navegadores e antes do surgimento do Chrome e do V8. A Google contratou gente boa para o V8, gente que desenvolvia os recursos de compilação adaptativa da linguagem Self, e que entendia do assunto. Com isso, ficou desnecessário o uso de recursos Frankstein do js2 para obter performance. Especificação de tipos de variável por exemplo não faria mais diferença, pois agora os compiladores JIT de js sabiam inferir muito bem os tipos das variáveis automaticamente. Também foram aplicadas técnicas do Self para aceleração da orientação a objetos usando protótipos.
Orientação a objetos usando protótipos não é primitiva. Ela é bem mais poderosa e simples de entender que a orientação a objetos usando classes. Ela foi inventada pelo pessoal do Self justamente porque acharam que a orientação a objetos usando classes se tornava cada vez mais confusa. Se um dia o js abandonar o uso desse tipo de orientação a objetos, estará regredindo, e não progredindo.
O que talvez não seja legal hoje é a API usada para trabalhar com js em páginas web. A API do DOM é um pouco esquisita. Mas frameworks como o jquery fazem bem seu trabalho expondo uma API mais bonita para o desenvolvedor, e tudo isso sem abdicar dos recursos modernos que o js sempre teve desde o início: orientação a objetos usando protótipos, closures, etc.