Esta é uma comparação de maçãs com laranjas. Veja http://redis.io/topics/benchmarks
O Redis é um remoto eficiente banco de dados. Cada vez que um comando é executado no Redis, uma mensagem é enviada ao servidor Redis e, se o cliente for síncrono, ele bloqueia aguardando a resposta. Portanto, além do custo do comando em si, você pagará por uma viagem de ida e volta de rede ou um IPC.
Em hardware moderno, as viagens de ida e volta de rede ou IPCs são surpreendentemente caras em comparação com outras operações. Isso se deve a vários fatores:
- a latência bruta da mídia (principalmente para rede)
- a latência do agendador do sistema operacional (não garantido no Linux/Unix)
- as faltas de cache de memória são caras, e a probabilidade de faltas de cache aumenta enquanto os processos do cliente e do servidor são agendados para entrada/saída.
- em caixas de última geração, efeitos colaterais NUMA
Agora, vamos analisar os resultados.
Comparando a implementação usando geradores e aquela usando chamadas de função, eles não geram o mesmo número de ida e volta para o Redis. Com o gerador você simplesmente tem:
while time.time() - t - expiry < 0:
yield r.get(fpKey)
Portanto, 1 ida e volta por iteração. Com a função, você tem:
if r.exists(fpKey):
return r.get(fpKey)
Portanto, 2 viagens de ida e volta por iteração. Não admira que o gerador seja mais rápido.
É claro que você deve reutilizar a mesma conexão Redis para obter um desempenho ideal. Não faz sentido executar um benchmark que sistematicamente conecta/desconecta.
Por fim, em relação à diferença de desempenho entre as chamadas do Redis e as leituras do arquivo, você está simplesmente comparando uma chamada local com uma remota. As leituras de arquivos são armazenadas em cache pelo sistema de arquivos do SO, portanto, são operações de transferência de memória rápida entre o kernel e o Python. Não há nenhuma E/S de disco envolvida aqui. Com o Redis, você tem que pagar o custo das viagens de ida e volta, então é muito mais lento.
