02 Worker
Thread principal e Worker
O mesmo tokenizador roda dos dois lados. No thread principal a barrinha para. No Worker ela continua. Eu também mostro o que acontece com a memória quando o buffer é transferido.
Como usar
O mesmo trabalho roda no thread principal e num Worker. No primeiro a tela trava. No segundo a barrinha continua.
- Deixe 280 cópias e 8000 rodadas.
- Aperte Comparar os dois.
- Leia o pior frame de cada lado e a frase embaixo.
O gráfico mostra o tempo de cada frame. Ciano até 20 ms, âmbar até 32 ms, vermelho acima de 32 ms. As palavras repetem o que a cor diz.
Ver o código, abre no GitHub em uma nova abaIndicador de travamento
Ainda sem frames medidos.
- até 20 ms, fluido
- até 32 ms, apertado
- acima de 32 ms, travado
A barrinha anda no requestAnimationFrame, não numa animação CSS.
Se o thread principal ficar ocupado, o próximo frame atrasa e a barra mais alta mostra o pico.
Uma long task é uma tarefa acima de 50 ms.
Carga
O sistema pediu menos movimento, então a barrinha começa parada. A medição de frame continua. Marque a caixa para ver o movimento mesmo assim.
Thread principal o trabalho e o frame disputam o mesmo thread
Aguardando
CPU ainda não
Pior frame ainda não
Long tasks na rodada ainda não
Palavras ainda não
Checksum ainda não
Web Worker o trabalho sai do thread que pinta
Aguardando
CPU ainda não
Pior frame ainda não
Long tasks na rodada ainda não
Palavras ainda não
Checksum ainda não
Parado Pronto
Memória transferida
Eu codifico o texto num Uint8Array e passo o ArrayBuffer na lista de transferência.
Isso move o buffer, não copia. Por isso o byteLength no thread principal fica 0:
o worker é o dono daquela memória. A string original continua aqui. O que zerou foi a cópia UTF-8.
Se eu mandasse a string direto, o structured clone duplicaria os bytes nos dois lados.
Transferir vale a pena para buffers grandes (pixels, áudio, pesos). O resultado pequeno volta como objeto normal.