Otimização de performance prematura: não faça!

Otimização de performance é uma preocupação comum para quem está começando em programação, e muitas vezes mesmo programadores experientes tem dúvidas sobre esse assunto, o que é normal uma vez que o assunto é mesmo complexo. Não vou explicar nesse post tudo o que você precisa saber sobre performance, mas pretendo dizer o mais importante: quando você precisa se preocupar. Isso mesmo, porque um erro muito comum é ver os programadores se preocupar demais com performance, na hora errada.

Então vamos lá: nossos computadores são muito potentes hoje em dia. Muito. Dificilmente mudar a lógica de um cálculo, criar uma variável a menos, otimizar um loop, ou até concatenar menos strings vai fazer algum diferença sensível. Então, não pré-otimize, não otimize antes de medir.

Vamos mostrar um exemplo. Fiz em Python só porque eu gosto, mas a mesma coisa vale para sua linguagem favorita. Escrevi os dois arquivos a seguir:

strings1.py

tamanho=20
a='a'
for i in range(tamanho):
    a*=2
print(len(a))

strings2.py

tamanho=20
a='a' * (2**tamanho)
print(len(a))

São duas maneiras bem diferentes de se criar uma grande string. A segunda é muito mais eficiente que a primeira. Bom, veja os resultados da execução aqui na minha máquina:

$ time python strings1.py
1048576
real 0m0.023s
user 0m0.013s
sys 0m0.008s
$ time python strings2.py
1048576
real 0m0.021s
user 0m0.012s
sys 0m0.008s

Nenhuma diferença prática, certo? Aumentei a variável tamanho para 30, agora notamos diferença:

$ time python strings1.py
1073741824
real 0m1.375s
user 0m0.671s
sys  0m0.691s
$ time python strings2.py
1073741824
real 0m0.586s
user 0m0.235s
sys  0m0.344s

Agora a diferença é absurda, certo? Mas quando foi a última vez que você precisou concatenar strings de um bilhão de caracteres? O caso é: se suas strings vão chegar a esse tamanho, você provavelmente vai saber disso antes. Por exemplo, se você está fazendo um software de tratamento de imagens, parece óbvio que processamento pode ser um problema, certo? Se não, gastar seu tempo e esforço com otimização de performance provavelmente não vale a pena.

Aviso: o código do exemplo 1 é muito ruim, além de dar mais trabalho para escrever. Eu não estou sugerindo que você escreva código ruim de propósito, tá? Apenas que você não se preocupe demais com performance e não gaste seu tempo resolvendo problemas imaginários.

Há, porém, algumas situações em que tudo o que eu disse acima não vale. Nossos processadores são muito rápidos, nossas memórias também. Discos já não são tão rápidos assim. Bancos de dados, mais ou menos. A internet, bom, quem pode confiar na internet, né?

Então, se você vai consumir um webservice, e pode mudar seu algoritmo para fazer dez chamados ao invés de vinte, faça isso. Se vai escrever muito no disco, e puder reduzir em 20% as operações de escrita de arquivos, faça isso. Se escrevendo uma consulta SQL mais complexa você consegue fazer muito menos consultas ao banco de dados e usar mais índices, faça isso.

Eu faço mais ou menos assim em relação a performance:

  1. Vamos usar a internet? Otimize sempre.
  2. Vamos gravar grandes arquivos, ou fazer uso intensivo de disco? Otimize sempre.
  3. Cálculo científico, tratamento de imagens e outras operações de processamento massivo? Otimize sempre.
  4. Bancos de dados com milhões de registros e uso intenso? Otimize sempre.
  5. Uso comum de arquivos e bancos de dados? Cuide de não escrever nada muito ruim, e otimize se der problema.
  6. O resto todo? Escreva pensando em legibilidade, encapsulamento e reuso. Só otimize se tiver problemas.

Publiquei um vídeo sobre isso há um tempo, se você quiser dar uma olhada: Não pré-otimize.

Site não seguro – como resolver de graça com Let’s Encrypt

No começo de 2017, o Google Chrome passou a mostrar um aviso para os usuários, com o texto “não seguro” na barra de endereço quando um site sem HTTPS pede dados do usuário. Classificou a maioria dos sites como “site não seguro”. Assim:

Aviso de site não seguro do Chrome

Essa mensagem aparecia apenas em situações onde o site potencialmente ia coletar dados dos usuários. Basicamente, quando havia um formulário na tela. Principalmente formulários de login, mas a mensagem aparecia para praticamente qualquer formulário. Logo, durante todo o ano passado, você poderia manter um site de conteúdo sem HTTPS, sem problema nenhum, desde que não tivesse formulários.

Recentemente, porém, o Google passou a avisar site não seguro para qualquer site sem HTTPS. Assim, até o Pudim, um site que não tem formulário, nem scripts, nem nada, só uma foto de um pudim, está marcado, veja:

Site Pudim marcado pelo Chrome como site não seguro
Até o Pudim agora é um site não seguro, pobre Pudim 🙁

Tenho um site não seguro. Como resolver? Let’s Encrypt!

Essa iniciativa do Google Chrome não está sozinha. Faz parte de um esforço de várias frentes para tornar a web mais segura. O próprio Google anunciou que está privilegiando nas buscas sites com HTTPS. Quer dizer que, ao estar marcado como site não seguro, seu site não apenas vai assustar os usuários que receber, também vai receber menos usuários.

O próprio Google Chrome, junto com empresas como GitHub, Facebook, Cisco e Akamai, patrocinam uma iniciativa chamada Internet Security Research Group, que oferece, através do Let’s Encrypt, chaves SSL grátis e automáticas para qualquer site.

Assim, se o seu provedor dá suporte a Let’s Encrypt, você provavelmente pode ter seu site marcado como seguro em poucos cliques. Meu hosting predileto, por exemplo, é a Dreamhost. Se você hospeda seu site lá, pode ativar SSL em seu site em três cliques, aqui:

Página Secure Hosting no painel da Dreamhost
Viu ali? Let’s Encrypt SSL.

Se você mantém seus próprios servidores, dedicados ou VPS, você vai ter que instalar o Let’s Encrypt você mesmo. O processo é bastante simples. Expliquei nesse vídeo:

HTTPS com Let’s Encrypt

Módulo Python: requests

Esqueça urllib e httplib: Requests resolve do jeito certo.

Você pode instalar via pip com:

pip install requests

Depois, veja como é fácil:

>>> import requests
>>> r=requests.get('http://visie.com.br')
>>> for k,v in r.headers.iteritems():print k,'=>',v
... 
content-length => 7669
content-encoding => gzip
accept-ranges => bytes
expires => Mon, 20 Jan 2014 13:18:30 GMT
vary => Accept-Encoding,Cookie
server => Apache
last-modified => Mon, 20 Jan 2014 12:38:24 GMT
cache-control => max-age=3, must-revalidate
date => Mon, 20 Jan 2014 13:18:27 GMT
content-type => text/html; charset=UTF-8
>>> r.status_code
200
>>> r.reason
'OK'
>>> r.content[:15]
'<!DOCTYPE html>'

Se você precisar fazer uma requisição HTTPS com autenticação e obter o retorno em JSON:

>>> r=requests.get('https://httpbin.org/basic-auth/user/passwd',auth=('user','passwd'))
>>> r.json()
{u'authenticated': True, u'user': u'user'}

Para fazer POST:

>>> r=requests.post('https://httpbin.org/post',data={'foo':'bar'})
>>> r.json()['form']
{u'foo': u'bar'}

Tudo muito, muito simples. E o módulo faz muito mais e está muito bem documentado. Olhe lá.

HTTP API WordPress

Você está desenvolvendo um plugin ou tema para WordPress e precisa fazer uma conexão HTTP? Não use fopen, curl, file_get_contents, etc. Use a HTTP API do WordPress.

A HTTP API é simples de usar, muito bem implementada e tem excelente performance.  E se um dia você precisar hospedar seu site num servidor debaixo de um proxy, não vai precisar reescrever seu código. Ao configurar o proxy no wp-config.php, tudo vai funcionar.

Veja um exemplo do uso da HTTP API:

$content=wp_remote_retrieve_body(
           wp_remote_get('http://visie.com.br/'));