Desempenho
Estes são números medidos, não promessas: cada valor desta página vem de um benchmark ou de uma medição registrada durante a construção do recurso que ele descreve, e cada um diz o que foi medido, como e quando. Rodando no seu hardware os números mudam — o formato é o que se mantém.
- Quanto leva uma execução em cada linguagem, de ponta a ponta
- Quanto custam um passo de flow e uma iteração de loop
- Por que ramos em paralelo levam o tempo do mais lento
- Como os números foram medidos, para você repetir
O que “rápido” quer dizer aqui
Uma execução é cronometrada do momento em que entra na fila até o momento em que o resultado é gravado, com horários que o próprio banco escreve. Isso inclui tudo o que uma pessoa espera: a fila, a escolha do worker, o início do sandbox, o código e a gravação da saída. Todo benchmark roda com o sandbox LIGADO, porque é assim que o seu código roda.
Uma execução, por linguagem
Medido: uma execução de script com a frota ociosa, sandbox ligado, horários gravados pelo banco (não um cronômetro no cliente), mediana de sessões repetidas numa frota recém-reiniciada · julho de 2026 · benchmark de execução do waiso-bench.
JavaScript e TypeScript seguem o mesmo caminho: TypeScript é compilado para o mesmo JavaScript e os dois começam num contexto de engine isolado que já está aquecido. Python pega um runner de um pool aquecido que já carregou o SDK da plataforma, então o script começa na hora. C e C++ são compilados uma vez e o binário fica em cache; a primeira execução de uma versão nova paga a compilação, as seguintes não.
Sob carga
Medido: rajadas de 32 execuções contra 3 workers com 12 slots cada, sandbox ligado; mediana de 16 sessões (JavaScript, TypeScript) ou 5 (Python, C, C++), cada uma numa frota nova · julho de 2026. TypeScript e JavaScript usam a mesma engine: nesse tamanho de rajada um lote termina numa onda só ou passa para uma segunda, por isso os dois trocam de posição de uma sessão para outra.
Passos de flow e loops
Medido: o benchmark de desempenho de passos rodando sozinho contra o ambiente real — um passo Python, um loop de 32 iterações e um flow de 8 passos, do início ao resultado gravado · outubro de 2026. Um runner aquecido é reservado quando o loop começa, então nenhuma iteração depois da primeira onda paga uma partida a frio.
Uma iteração de loop custa cerca do dobro de um passo porque cada iteração é um job com o próprio sandbox: nenhum estado vaza de um item para o próximo. Quando as iterações rodam em paralelo (o grau do loop), o tempo total fica perto do número de iterações dividido pelo grau, vezes uma iteração.
Medido: um nó Ramos em paralelo com três ramos Python esperando 2 s, mediana de 5 execuções em 3 workers · outubro de 2026. A barra de um de cada vez é a soma das três esperas.
Imports entre scripts
Medido: 20 execuções de um script Python, com e sem importar uma biblioteca de uma pasta do mesmo projeto · outubro de 2026. Da fila ao fim: 34 contra 36 ms.
As bibliotecas que um script importa viajam junto com o job e são gravadas ao lado dele antes de o código começar, e o runner aquecido já pagou pela maquinaria de import — então reutilizar código custa cerca de um milissegundo.
Repita as medições
- Meça com o sandbox ligado e pelos horários do servidor; um cronômetro no cliente soma o próprio tempo de rede.
- Reinicie a frota entre linguagens: uma linguagem medida depois de outra herda um sistema aquecido e parece mais rápida do que é.
- Use a mediana de várias sessões; uma rajada só perto da capacidade de slots tem muito ruído.
- Os workers vêm com 12 slots cada; mais slots ajudam execuções que passam o tempo esperando e não mudam nada para as que ocupam a CPU.
| Número | Valor | Quando |
|---|---|---|
| Uma execução Python sozinha | 21 ms | julho de 2026 |
| Passo de flow / iteração de loop | 23 / 45 ms | outubro de 2026 |
| Três ramos paralelos de 2 s | 2,1 s | outubro de 2026 |
| Custo de um import | +1 ms | outubro de 2026 |