PplWare Mobile

PHP é à quinta-feira – 50 dicas sobre desempenho e segurança

                                    
                                

Este artigo tem mais de um ano


Autor: Pedro Pinto


  1. PeTiNgA says:

    Deixo aqui outro bom site com resultados de benchmarks em PHP: http://www.phpbench.com/

    • JGomes says:

      Esse site também tem testes interessantes, já faz parte dos meus favoritos 😉

      Obrigado por partilhares!

      • Nuno Peralta says:

        Como é que é possível nesse site dizer que “echo ”, ”, ”,” é pior do que usar “echo ”.”.”.” ?!!!!

        • JGomes says:

          Tem a haver com o modo de funcionamento do PHP e da funcão echo.

          O echo na verdade não é igual às funções, mas sim um “language construct” – Tanto que não precisas de parentesis – e e suporta multiplos parametros

          echo “string”.”string”.”string”; estás a utilizar um parametro e a concatenar 3 strings, e depois faz o output das finais. Caso não saibas, as strings são imutáveis, o que quer dizer que para juntares 2 strings tens que criar uma nova com o tamanho das 2, copiar o conteúdo e destruir as anteriores.

          echo “string”,”string”,”string”; estás a utilizar parametros, que são processados mais rapidamente pelo php. Esta parte não te sei explicar correctamente, mas o echo na verdade consegue processar mais depressa usando multiplos parametros que concacatenações.

        • JGomes says:

          quanto ao site, sinceramente não faço a mais mínima ideia porque tal ocorre…

      • Nuno Peralta says:

        (o que contraria o ponto 4 aqui dito no pplware)

  2. avlis rotiv says:

    😆
    “PHP é a…” PHP é à… 😀
    Torna-se um vício! 😛

  3. Pedro Pinto says:

    Excelente artigo Jorge Gomes !!!!
    Tudo que leve a performance é sempre bem vindo.

  4. Ana Narciso says:

    Excelentes dicas! Tive contacto com PHP há poucos meses e por isso aprendi imensas dicas com o teu artigo. Parabéns!

  5. cf says:

    Muito bom!
    Obrigado

  6. JGomes says:

    obrigado pessoal 😉

    Esqueci-me de deixar uma nota, existe ainda muito pessoal que programa para versões de PHP 5.2 ou inferiores com funções da biblioteca de Regex POSIX (entre elas ereg(), eregi(), split()). Estas funções estão todas DEPRECATED no PHP 5.3 e serão removidas no PHP6, por funções da biblioteca PCRE que têm melhor desempenho e funcionam praticamente do mesmo modo.

    Lista de funções POSIX regex:
    http://www.php.net/manual/en/ref.regex.php

    Lista de funções PCRE:
    http://www.php.net/manual/en/ref.pcre.php

    Evitem também utilizar o operador de referência & em objectos, pois estes desde do PHP 5 que são sempre passados por referencia.

    Cumprimentos

  7. Obrigado! Vai dar jeito com certeza.

  8. Márcio Santos says:

    oh Jorge Gomes

    Fantástico artigo. Conjunto de dicas magnífico. Sem dúvida sensacional.

    Parabens

  9. Bónus says:

    Parabéns!
    Excelente artigo!
    Embora já conheça algumas dicas, a maioria (quase todas), não conhecia, principalmente as diferenças de rapidez dos métodos utilizados. São “pequenas” diferenças, mas acredito que todas juntas, façam diferença.
    Muito bom mesmo! 😉

    • JGomes says:

      exactamente, na maioria dos casos falamos de diferenças de uns insignificantes milissegundos (tanto que é difícil realizar benchmarks conclusivos), mas tal como o provérbio popular “grão a grão enche a galinha o papo”, uma aplicação PHP complexa que utiliza milhares de vezes estas funções irá beneficiar de um enorme ‘boost’ de desempenho.

  10. TiagoKito says:

    Muito obrigado pela partilha =D

  11. phoenux says:

    Obrigado pelo artigo que contém algumas dicas bastante interessantes e que fazem bastante sentido. Pessoalmente só fiquei com algumas dúvidas na dica nº8 (“Utilize require() / include() invés de require_once() / include_once(), pois estas últimas necessitam de verificar se o ficheiro já não foi incluído no código”), não que a dica esteja errada, mas talvez porque a justificação não esteja tão correcta; na realidade o require_once não é significativamente mais lento do que que o require; os testes que o Peter Bowyer fez são é um pouco tendenciosos e, se inverteres a ordem dos testes, os resultados poderão ser bem diferentes; ao inserir o require_once em primeiro lugar é feita uma chamada ao sistema por cada um dos directórios que constituem o caminho até ao ficheiro a incluir para verificar as permissões de cada um deles; se existirem permissões até ao ficheiro e se este puder ser lido, então está será aberto e, só neste momento é que será analisado se o ficheiro já foi incluído ou não na compilação (este processo poderá ser ainda mais demorado, se o caminho para o ficheiro for relativo). Se após a instrução require_once fizermos um require, esta última será muito mais rápida pois poderá ter em cache o processo de análise de todos os directórios até ao ficheiro não tendo de repetir este processo novamente. (Se quiserem saber mais sobre isto, recomendo a leitura deste comentário http://www.php.net/manual/en/function.require-once.php#90017).

    “Então mas a dica estava errada?” Não necessariamente e não existe um grande consenso relativamente a este tema. Pessoalmente prefiro utilizar o require_once por uma questão de comodidade e de manutenção de código. Em todo o caso, é relativamente simples e replicar a funcionalidade do require_once utilizando require: no ficheiro que estão a incluir definem uma variável com um nome único para todo o projecto e, transformam os vossos habituais require por algo deste tipo:

    if(!isset($nome_da_variavel)) require(‘caminho/nome_do_ficheiro’);

    Um abraço

    • JGomes says:

      evita colocares “wall of text” nos comentários, custa um pouco a ler.

      Tal como outras dicas que estão no tutorial, a diferença entre o require() e require_once() é muito muito pequena, se a aplicação for pequena.

      “The time difference between require_once() vs. require() is so tiny, it’s almost always insignificant in terms of performance. The one exception is if you have a very large application that has hundreds of require*() calls.”

      Eu pessoalmente utilizo também o require_once para não existir código repetido (um exemplo de escolha entre escalabilidade vs performance).

      Quanto à dica, esta talvez esteja ambígua mas o objectivo é comparar o require/include com o include_once / require_once:

      Assumindo que os ficheiros existem e o caminho fornecido está correcto, o require irá sempre incluir o código fonte no programa mesmo que este ja tenha sido incluido anteriormente.

      No entanto o require_once vai verificar se o ficheiro ja foi incluindo, e isso leva tempo (por mais insignificante que seja) e caso positivo, não o inclui.

      Nota: se não estou em erro, se fizermos require() e de seguida require_once() do mesmo ficheiro, este é incluído em ambos os casos no programa.

      Cumprimentos

  12. Rui Peixeiro says:

    Excelente tópico.

    Apesar de já trabalhar com PHP há uns anos e ter cuidado para melhorar a performance, ainda deu para aprender muito com este tópico.

    Tenho de fazer umas revisões nos meus códigos!

  13. Cosme Benito says:

    Mas que excelente artigo. Muitos parabéns.

    Vou já começar a optimizar o meu código 😀

Deixe um comentário

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.