Meu primeiro artigo no blog, uma tradução do otimo post de Reinhold, depois desse espero ter sempre artigos e traduções de qualidade sobre PHP. ( fiz algumas alterações e coloquei links para alguns artigos relacionados)
[UPDATE]
Algumas correções de português, adicionados exemplos.
Obrigado Pablo.
[/UPDATE]
Ai esta: (Thank you Reinhold)
- Se um método pode ser estatico, declare ele estatico. O fator de otimização é 4x+
- echo é mais rapido que print. Veja
- Prefira usar echo com multiplo parametros ao invés de concatenar string
-
echo "parametro um", $var , "outro parametro"
-
- Set o valor maximo do seus loops FOR antes e não no for
#onde:
-
for($i=0;$i<count($array);$i++)
-
#use:
-
$max_for = count($array);
-
for($i=0;$i<$max_for;$i++)
-
- Sempre de unset em variaveis que nao serão mais usadas, principalemente grandes arrays.
- Tente não usar métodos magicos, como: __get, __set, __autoload
- require_once() tem custo elevado, prefira include[_once], como alertado pelo Pablo, o include_once é mais custoso que o include.
- Use caminhos completos em includes e requires, o PHP gastara menos tempo resolvendo os caminhos.
- Se você deseja descobrir quando o script começou a ser executado, $_SERVER[’REQUEST_TIME’] é melhor que time()
- Se você puder, use strncasecmp, strpbrk e stripos no lugar de funcões regex
- str_replace é mais rápida que preg_replace, mas strtr é ainda 4x mais rapida que str_replace.
- Se uma função, como troca de string , aceitar tanto arrays quanto caracteres unicos e a sua lista de argumentos não for muito longa, considere escrever algumas vezes o mesmo codigo passando um caracter por vez ao invés de uma linha passando arrays nos argumentos de pesquisa e troca.
- É melhor usar switch/case do que multiplos if’s e else.
- Usar supressão de erros com @ na frente da função é muito lento.
- Ative o mod_deflate do apache( modulo de compressão de resposta).
- Feche as conexões ao banco de dados quando você não for mais usa-lo.
- $row[’id’] é 7x mais rapido que $row[id]
- Mensagens de erros tem custo elevado, desligue-as em produção.
- Não use funcões dentro de loops, como:
-
for ($x=0; $x < count($array); $x)
A função count() é chamada em cada iteração.
-
- Incrementando uma variavel local é mais rapido.
- Incrementando uma variavel global é 2x mais lento que em uma variavel local.
- Incrementando uma propriedade ( $this->prop++) é 3x mais lento que em uma variavel local.
- Incrementando uma variavel local não definida é de 9x a 10x mais lento do que uma variavel local pré-inicializada.
- Declarando uma variável global sem usá-lo em uma função também atrasa as coisas (com aproximadamente a mesma quantidade incrementando como uma variavel local).O PHP provavelmente faz um checagem para ver se existe a nível global
- A invocação de métodos parece ser independente do número de métodos definidos em uma classe, em uma classe de teste onde se adicionou 10 metódos não teve mudança de performance.
- Métodos em classes derivadas rodam mais rápido do que aqueles definidos na classe base.
- Use ‘ ao invés de ” em strings quando não for preciso usar variaveis ou escapes, assim o PHP não necessita procurar e interpretar esses caracteres especiais.
- Prefira usar HTML puro se for possivel, scripts PHP são servidos de 2x a 10x mais lentos que equivalentes.
- Em cada requisição seus scripts PHP são recompilados, use uma solução de cache, isso pode te dar um ganho de 25 a 100% . Veja
- Quando lidando com string e você precisar verificar se a string possui certo tamanho, você entendidamente desejara usar a função strlen().
Essa função é bastante rapida, já que ela não faz nenhum calculo, apenas retorna o tamanho ja conhecido da string disponivel na estrutura zval(estrutura interna do C usada para guardar variaveis PHP). No entanto como strlen() é uma função ela ainda assim é lenta, porque o PHP precisa fazer varias operações como lowercase e buscas na hashtable, e em seguida executar a dita função.
Algumas vezes você podera aumentar a velocidade do seu código usando um truque com isset().
Exemplo: Digamos que voce tem :if (strlen($foo) < 5) { echo “Foo is too short”; }-
# versus
-
if (!isset($foo{5})) { echo "Foo is too short"; }
Usando isset() sera mais rapido que strlen(), porque diferente de strlen(), isset() é um construtor de linguagem e não uma função, isso quer dizer que a sua execução não necessita busca na hashtable nem uso de lowercase. Virtualmente você não sobrecarga no código atual para determinar o tamanho da string.
-
- Quando incrementando ou decrementando o valor de uma variavel, $i++ normalmente é mais lenta que ++$i. Isso é especifico para PHP, ou seja, não se aplica a outras linguagens, não sai por ai modificando seu código java ou C. Isso se da porque $i++ usa 4 opcodes enquanto ++$i precisa de somente 3.
- Nem tudo precisa ser OOP, gera muita sobrecarga, cada chamada de método e objeto consome um monte de memória.
- Não implemente cada estrutura de dados como uma classe, arrays são utéis também.
- Não divida muito os métodos, pense bem cada código que sera reusado.
- Você sempre podera dividir o código no futuro, caso necessario.
- Faça uso das incontaveis funções pré-definidas.
- Se você tem muito tempo consumido por funções em seu código, considere escreva-las como extensões C.
- Faça Profile do seu código. Um profiler mostra quanto tempo cada parte do seu código consome. A extensão Xdebug ja contém um profiler.
- Excelente artigo sobre otimização PHP de John Lim (inglês)
19 comments ↓
Muito boa as dicas, vlw
[...] por Lucas Stephanou (lucasΘlucas-ts·com) - referência [...]
Muito valiosas as dicas, foi para os favoritos =)
Adorei também, já vou adicionar no meu delicious
Ótimo post!
Só um comentário:
i++ é mais lento que ++i em C++ também.
Vou comentar apenas alguns itens, acho que vai ter gente discordando do que eu digo, claro, mas normal, né?
“7 - require_once()tem custo elevado, prefira include[_once]”
include_once tb tem custo elevado. Use sempre include. include_once vai registrar cada um dos includes e sempre parar para verificar se o include já foi feito ou não antes de fazer outro include. O correto é a pessoa aprender a programar e parar de sair distribuindo includes no código.
“14 - Usar supressão de erros com @ na frente da função é muito lento.”
Ok, faltou colocar um exemplo do que deveria ser feito, como display_errors… ou qq coisa assim. Agora, o correto era estar definido “Sempre mostre todos os erros, Notices de variáveis não inicializadas são tão importantes quanto Fatal Errors. Seu código não deve ter NENHUMA mensagem. Trabalhe sempre com os alertas no máximo”. Aqui fazemos assim, e a quantidade de falhas tem reduzido horrores. O problema é convencer as pessoas a fazer isso… “Ah, em produção não deve”… UMA OVA QUE NÃO DEVE! 99,99% dos erros acontecem é em produção,
e sem ter nenhum feedback fica quase impossível depurar ou às vezes até mesmo repetir o erro.
“17 - $row['id'] é 7x mais rapido que $row[id]”
Se a pessoa seguisse o que eu acabo de colocar sobre o item 14, JAMAIS ia ter escrito $row[id], porque ia ganhar um NOTICE bem cabeludo.
“18 - Mensagens de erros tem custo elavado, desligue-as em produção.”
Não tem custo tão elevado quanto a existência do erro. E se o erro existir, é porque a pessoa programou mal. Resposta do item 14 permitiria até que se desativasse, mas a verdade é que não deve ser desativado se você quer ter um sistema que funcione redondo. Você poderia, em tese, desativar depois de um tempo com o sistema funcionando (algo como um período de homologação), mas meu conselho é que não seja desativado.
“23 - Incrementando uma variavel local não definida é de 9x a 10x mais lento do que uma variavel local pré-inicializada.”
Voltando ainda ao item 14, se estiver com as mensagens de erro a FULL, vc nunca utilizará uma variável não inicializada, porque vai aparecer um monte de NOTICE. Então, se vc ganhou de 9x a 10x de performance, isso praticamente anula o item 18.
“27 - Use ‘ ao invés de ” em strings quando não for preciso variaveis ou escapes”
Ia ser legal explicar o motivo às pessoas. “Assim a engine do PHP não irá parar para interpretar strings que não precisam interpretação”.
Bom, basicamente é isso.
Um abc
Ola Pablo,
Não concordo com tudo que você falou :-), mas alterei algumas partes da tradução.
abs
Æ!!
Muito bom!
Precisamos de mais matérias como essa na internet por aí!
Há braços
Cara, parabéns pelo trabalho de tradução deste ótimo artigo. Só gostaria de contribuir opinando só um pouco
Primeiro era que seria melhor se você melhorasse esta parte de apresentação que fica dentro de tags
. fica ruim demais de ler desta forma, ainda mais pq ele colocou como como MENOR QUE 5, como < 5. E outra que tá misturado o código com explicações, que poderiam estar fora dai, entende ? Bem, é só para melhorar mesmo.Quanto ao que o Pablo falou, até concordo com ele em muitas coisas, só que ligar mensagens de erro em produção não acho legal não, já que expõe o sistema. Acho que o ideal é que as mensagens sejam direcionadas para um log que tem que ser verificado, ai sim, concordo plenamente, como forma de depurar e otimizar o sistema ao máximo.
Bem, acho que é isso.
Valeu
Foi alguma coisa na ultima edição
Ja corrigi.
[...] programas feitos em php, performace e tráfeco dos feitos em JavaScript, por isso o Lucas deixou 39 dicas para melhorar a perfomace na hora de codar em [...]
Na dica nº 30, quando recomenda a utilização isset no lugar de strlen pode realmente ser mais rápido, porém não é semânticamente correto e só em casos extremos de economia de recursos eu consideraria uma solução como essa.
Mas as dicas em geral são muito boas.
[...] Uma boa programação faz toda a diferença no resultado de um site, principalmente quando ele possui muitos acessos, que é a intenção de 99% dos sites. Eu não poderia deixar de compartilhar estas dicas que encontrei no blog do Lucas. [...]
Amigo Pablo, parabéns…
Li seu exelente artigo e já anotei em meu caderno de lembretes.
As dicas fazem muito sentido, mas pelas turbulências dos prazos, nunca parariamos para notá-las.
Valeu mesmo pela contribuição.
Pow cara, gostei muito das dicas!
Parabéns pelo post.
Muito boas as dicas. Qualquer informação que ajude é bem vinda.
Algo que eu poderia acrescentar:
Esse for abaixo é um pouquinho mais rápido (em termos computacionais,
Aos olhos humanos não diferem muito):
$max_for = count($array);
for($i=$max_for;$i>0;$i–)
Isso pelo simples fato de que o interpretador já tem
um valor a ser alcançado (zero) definido ao invés de correr
até o fim da iteração e receber uma mensagem de “end”
do array/valor usado. Mas como eu disse isso acontece quase que instantaneamente então o uso fica
a critério pessoal.
De novo, obrigado pela tradução das dicas.
muito bom, são coisas se nos deixam com dúvidas e que não temos tempo de pesquisas.. adorei..
Quem vai dar manutenção nesse código? Espero que não seja eu…
Oi, não funcionou o strtr em uma função que tenho que retira a formatação do texto.
E não consegui encontrar na configurações do meu apache o tal de mod_deflate para ativar…
Leave a Comment