Em um artigo sólido, bem fundamentado, Drew Crawford expõe todas as razões pelas quais ele acredita que os aplicativos web mobile são lentas hoje e porque ele não espera por uma melhoria relevante no futuro próximo. O artigo é o seguimento de um artigo anterior no qual ele aponta que o desempenho do JavaScript em dispositivos móveis é uma ordem de grandeza mais lento do que em computadores desktop. Este artigo foi duramente criticado, então Drew escreveu esse artigo muito mais elaborado. As razões para o baixo desempenho e a falta de melhorias dividem-se em três categorias:
- Velocidade dos procesadores ARM dos dispositivos móveis versus dos processadores x86 dos computadores desktop;
- Tendências de desempenho dos interpretadores de JavaScript;
- Consumo de memória particularmente relacionada ao garbage collection.
Os dois gargalos que Drew descreve são CPU e memória. A limitação pela CPU tem dois aspectos: o poder da sua CPU e a eficiência de execução. Drew aponta que a geração atual de processadores x86 são 10 vezes mais rápidos do que a atual geração de processadores ARM que são usados nos dispositivos móveis de hoje como o iPhone e dispositivos de alta qualidade com Android.
Eu não sou um engenheiro de hardware, mas certa vez trabalhei para uma grande companhia de semicondutores e as pessoas me dizem que o desempenho atual é principalmente uma função do seu processo (por exemplo, a coisa que eles medem em "nanômetros"). O desempenho impressionante do iPhone 5 deve-se, de maneira significativa, ao encolhimento do processo de 45nm para 32nm - uma redução de cerca de um terço. Mas para repetir o feito, a Apple teria de reduzir para um processo de 22nm.
O conhecimento e investimento na redução do tamanho de transistores está principalmente na mão da Intel. Drew afirma que não é provável que o ARM surpreenderá num futuro previsível. Na verdade, é muito mais provável que a Intel venha a produzir um processador x86 para competir em estratégia de consumo de energia, com o ARM do que fazer com que o ARM elimine esta lacuna de desempenho.
O segundo aspecto do desempenho é a eficiência. Quão eficientemente os ciclos da CPU são usados, isto é, quão eficiente podem ser as instruções de máquina geradas a partir de código JavaScript?
É aqui que muitos engenheiros da computação competentes tropeçam. Sua forma de pensar funciona da seguinte maneira: JavaScript tem se tornado mais rápido! Ele continuará ficando mais rápido!
A primeira parte é verdade. JavaScript tornou-se muito mais rápido. Mas estamos agora no Pico JavaScript. Não fica muito mais rápido daqui pra frente.
Este é o Chrome v8 no meu Mac (o mais antigo que ainda funciona, Dez 2010). E este é o v26:
Não percebe a diferença? É porque não há. Nada terrivelmente importante aconteceu ao JavaScript ultimamente, no que diz respeito à limitação pela CPU.
Se a rede parece mais rápida do que em 2010, é provavelmente porque o computador mais rápido, mas não tem nada a ver com melhorias do Chrome.
O motivo pelo qual o desempenho do JavaScript não tem mudado significativamente é claro, segundo Drew:
A questão é, usar uma abordagem JIT com JavaScript foi uma ideia de 60 anos de idade com 60 anos de pesquisa e literalmente milhares de implementações para cada linguagem de programação concebível demonstrando que era uma boa ideia. Mas agora que terminamos, ficamos sem ideias de 60 anos de idade. É isso, pessoal. Talvez possamos criar outra boa ideia nos próximos 60 anos.
A segunda limitação da Internet móvel é a memória. Mais uma vez há dois aspectos ligados ao uso da memória: a quantidade disponível e a eficiência do uso.
Enquanto dispositivos móveis modernos tem uma quantidade razoável de memória (normalmente 512MB ou 1GB de memória), o sistema operacional não permite o aplicativo usar essa quantidade toda. Muita memória é usada pelo sistema operacional em si, assim como por outros aplicativos trabalhando (multi-tarefa)
[...] essencialmente no iPhone 4S, é necessário se preocupar quando a aplicação usar em torno de 40MB, por que se atingir 213MB a aplicação é encerrada. No iPad 3, preste atenção quando chegar a 400MB porque a aplicação é encerrada se atingir 550MB.
Drew nota que com a resolução do iPhone 4S, uma única foto tirada com a câmera consome até 30MB de dados bitmap. Isso significa que há espaço disponível para 7 fotos na RAM antes que o sistema operacional desligue o aplicativo porque ficou sem memória. Portanto, especialmente se um aplicativo lida com imagens e vídeo, ele deve ser extremamente cuidadoso com que mantém na memória e por quanto tempo, uma vez que a memória é extremamente limitada.
O segundo aspecto da memória é eficiência. O JavaScript é uma linguagem com garbage collector. O desenvolvedor não tem de fazer o gerenciamento manual da memória, o que é desenhado para tornar a vida mais fácil para o desenvolvedor. Contudo, a garbage collection tem seu preço. Um preço que aumenta exponencialmente em ambientes restritos pela memória.
O que esse gráfico diz é: "Enquanto tiver cerca de 6 vezes a quantidade de memória que realmente precisa, estará bem. Mas terá problemas se tiver menos do que 4x a memória necessária".
A verdade é que no ambiente limitado pela memória, o desempenho do garbage collection decai exponencialmente. Se escrever Python ou Ruby ou JS que roda em computadores desktop, é possível que toda sua experiência esteja no lado direito do gráfico, e pode passar toda sua vida sem experimentar um garbage collector lento. Gaste algum tempo do lado esquerdo do gráfico e veja com o que o resto de nós lida.
Esse comportamento poderia ser a razão pela qual a Apple nunca tenha dado suporte ao garbage collector do Objective-C no iOS e o esteja substituindo pelo ARC (no iOS e no Mac), que não é um garbage collector.
Apesar de Drew levantar pontos interessantes em seu artigo, como apontado por Brendan Eich em um tweet, nem todos os aplicativos são limitados por CPU ou memória. Apenas uma certa categoria de aplicativos esbarra nesses problemas, por exemplo: jogos e aplicativos de fotos e vídeos. De qualquer maneira, o artigo de Drew (com 10.000 palavras) vale ser lido por qualquer um interessado em desempenho na Internet móvel.