O PHP continua a longo prazo como a linguagem de servidor favorita do mundo em termos de adoção. A linguagem ubíqua continua a evoluir à medida que a equipe impulsiona novas melhorias, agora as melhorias de GC estão chegando ao PHP 7.3.
O garbage collection é um método de gerenciamento de memória em tempo de execução da linguagem de programação. Ao contrário de linguagens não gerenciadas como C, C ++ e Objective C, onde os usuários precisam alocar memória, as linguagens com um GC como Java, JavaScript e PHP gerenciam isso automaticamente nos bastidores.
Em geral, o gerenciamento manual de memória permite um melhor desempenho, pois os usuários podem definir especificamente a alocação de memória na pilha e no heap. No entanto, a prática é demorada e é por isso que as linguagens de garbage collection são usadas pela maioria das tarefas de computação de alto nível que exigem alta eficiência. Estes incluem aplicativos da web para os quais o PHP é mais adequado.
Dmitry Stogov trabalhando na Zend no core do PHP runtime, realizou um merge de um pull request significativo a linguagem. O PR 3165 é rotulado modestamente como “melhoria de GC”, mas o trabalho tem efeitos potencialmente grandes em aplicações PHP que lidam com quantidades de memória.
O garbage collection sempre vem com alguma penalidade de desempenho, portanto, as melhorias afetarão o desempenho em toda a linha – mas a quilometragem variará dependendo da tarefa em mãos.
PHP 7.3 melhora ainda mais o gerenciamento de memória, JIT no PHP 8.0
O lançamento principal anterior, o PHP 7.0, trouxe melhorias significativas de desempenho ao tempo de execução. Estas foram em grande parte melhorias no gerenciamento de memória. Juntamente com a rápida hospedagem VPS e o PHP pode realmente se expandir muito além da série 5.x. Espera-se que isso também melhore, pois o PHP 8.0 traz o JIT para a linguagem.
A tendência de desempenho continua com cada versão do PHP 7.x ficando mais rápida. Com a data de lançamento do PHP 7.3 definida para o final de 2018, os usuários terão acesso a essa melhoria de GC muito em breve em suas aplicações. A queda nas mudanças para a maioria das aplicações gera aumentos significativos nos benchmarks iniciais com aplicações do mundo real:
// Very, very, very many objects GC | OLD | NEW disabled | 1.32s | 1.50s enabled | 12.75s | 2.32s // Very many objects GC | OLD | NEW disabled | 0.87s | 0.87s enabled | 1.48s | 0.94s // Less many objects GC | OLD | NEW disabled | 1.65s | 1.62s enabled | 1.75s | 1.62s
Os resultados indicam claramente que há muito espaço aqui. Com um grande número de objetos, o PHP acelera em uma tremenda escala. Isso será especialmente útil para Full Stack Frameworks, como o Laravel ou o Symfony. Estes são comumente usados para aplicações de gerenciamento de conteúdo ou e-commerce, nos quais objetos grandes são frequentemente manipulados.
É assim que Dmitry descreve suas descobertas:
- Com o GC habilitado, isso ainda é 1.5x mais lento que com o GC desativado (anteriormente era quase 10x mais lento). Isso ocorre porque o backoff do limite de GC (linear) acontece muito lentamente para esse caso. Eu acho que isso é bom para começar.
- Com o GC (runtime) desativado, temos uma lentidão da antiga para a nova implementação (1.32s a 1.50s). perf mostra que 10% do tempo é gasto dentro do
gc_remove_compressed.Portanto, essa carga de trabalho usa objetos suficientes para que o esquema de compactação se torne um problema …
https://github.com/php/php-src/pull/3165#pullrequestreview-100399813
Autor Original: Jorgé
Obrigado por enviar o seu comentário minha jóia!