JIT no PHP: ganhos de performance com Just-In-Time Compilation

Eu não negativei suas postagens, mas imagino que tenham negativado por parecer algo feito com IA, as pessoas não gostam disso, gostam de algo que seja relevante, que traga algo novo e não que possa ser lido em qualquer lugar, que não tenha personalidade, que não seja além de um fato, uma experiência que a pessoa tem para contar. Posso estar enganado, mas queria dizer isso para que tenha uma experiência melhor usando aqui.

Resolvi replicar este porque é de um assunto que entendo um pouco e vi que o texto é bem marketeiro, ou seja, fala como se fosse uma propaganda da tecnologia, outra coisa que as pessoas não gostam muito, a não ser que seja a tecnologia que ela ama e a pessoa tem uma quantidade de neurônios ativos um pouco menor. O ponto principal é "recurso poderoso chamado JIT". Quem disse que é poderoso?

Um JITter traz benefícios e malefícios. Mesmo um que possa ser chamado de estado da arte, não é vantajoso em várias situações. Especialmente o PHP 8, como citado ele veio mais para dizer que tinha, vários testes foram feitos e essencialmente não houve vantagem, algo que é quase impossível ser acontecer com algo que se transforma em código nativo, mas não acompanho tão de perto para descobrir porque isso aconteceu e eu sei que a comunidade de PHP não costuma ser muito ávida por conhecimento aprofundado ou que exige explicações de como as coisas funcionam ou falham, não há muito interesse por método científico, apenas por crenças.

Acabei de mostrar mais um tipo de texto que atra i negativos, mas também tem que positive por falar a verdade.

Certamente houve melhoras nas versões seguintes, mas não vi nada muito a respeito, o que indica que talvez não tenha sido muito melhorado, mas ficarei muito satisfeito e grato se alguém que acompanha mais postar algo.

Essa questão de linguagem interpretada ou não é mais complicado, o termo interpretação não cabe mais na maioria das linguagens, quase todas são compiladas sob demanda, ou seja, quase tem um JITter de qualquer forma, mas convencionou-se chamar de JITter quando se gerar um código nativo, algo que PHP não fazia, mas agora, em tese, faz. Antes ele gerava um código de execução em uma forma de assembly de uma máquina virtual, o tal do Zend Engine. Não está totalmente errado falar em interpretação se considerar que esse bytecode (ou opcode) gerado na compilação sob demanda é interpretada pela VM, mas não é a interpretação tradicional que ocorria no passado, apenas é o caso de passar por um loop que manda executar o que precisa, algo que o nativo esse loop é inter ao processador e não custa nada de processamento. Pode falar em uma camada extra mais do que interpretação, caso contrário o processador também interpreta códigos.

O código-fonte é lido pelo Zend Engine.
Esse código é transformado em uma representação intermediária chamada opcode.

Isso é o que chamados de compilação.

Aí vamos para os melhores resultados. Em qualquer JITter ou compilação AOT de linguagens que nbão são de scripts é comum melhorar 3 vezes ou mais a execucação que qualquer código que não faça IO. Alguns que fazem IO podem melhorar ainda significativamente, embora bem menos. E outro a melhora é mínima, mas acontece. PHP não consegue isso, e é muito estranho.

Quando à ressalva que não melhora muito CMS, APIs e afins, bem, PHP é usado praticamente só para isso, inclusive o criador da linguagem me disse pessoalmente que é só para isso e está errado quem usa para outras coisas. Então se o ganho para isso é muito pequeno, pra que investir nisso?

É nessas horas que eu falo que os produtores de PHP tomam muitas decisões erradas e por essa razão, apesar de tear alguma melhoras, tem várias piores em relação à versões anteriores, pelo menos para o que ele se propõe ser.

Mas vamos falar dos itens citados que não vão melhorar muito.

Acesso à "disco", não importa a que, é claro que o ganho será pequeno, mas não deveria não existir. E os frameworks extremamente complexos que as pessoas costumam usar fazem que boa parte desses acessos sejam processamento e não o IO (não estou falando que é a maioria, embora possa ser eventualmente já que há otimizações do SO ou DB que pode estar lendo da memória).

Tempo de rede dentro da normalidade não deveria importar, a não ser que a pessoa esteja fazendo algo muito mais complexo do que deveria, arquitetando algo por modinha e não pela necessidade, ou ainda se há a necessidade, PHP não deveria ser a ferramenta correta. lembre-se que o tempo de rede para receber a requisição ou enviar a resposta não deveria ser considerado para essa avaliação, é igual para to9das as tecnologias, a medição deve ser só enquanto processa desde a entrada, o miolo principal e a saída, mas nada além disso.

E algo importante: o ganho é interessante para atender mais requisições, não importa tempo de rede. Também não deveria importar tento assim o acesso a armazenamento de massa se tudo estiver adequadamente dimensionado, embora quem trabalha com PHP não costume pensar nisso, mais um motivo para que o JITter pode ter sido criado apenas para manter a audiência cativa "dizendo" algo como: "temos tudo o que as outras linguagens têm, não precisa ir embora, fique aqui".

Pelo que eu sei não houve muita melhorai até mesmo quando se manipula dados exclusivamente em processamento, embora ela exista. E novamente, algo que PHP raramente faz.

Em alguns casos pode ser vantagem desativar o JITter, algo que pode ser medido, mas só isso, então na prática não precisa mesmo, o ganho será imperceptível para quase qualquer caso.