3 de abril de 2014

FOR ALL ENTRIES: pode até ser seu colega, mas cuidado com ele

Fala pessoas (olha, um arbusto seco rolando ao vento...)

Vamos iniciar nossa série sobre performance, que terá um total de partes equivalente ao quadrado do grau de inclinação do rabo do hipopótamo.

Não vou abordar os conceitos iniciais de performance, como selecionar somente os campos necessários no select, não usar tabela com cabeçalho, não contratar aborígenes de Papua para ficar imputando NFe e outros. Mas caso achem necessário, deixe comentários no post solicitando os conceitos básicos de performance (ou seja, como não tem ninguém lendo, não vou ter que fazer).

Inicialmente, vamos falar de FOR ALL ENTRIES.
Esse prezado e dileto comando pode até ser nosso colega, mas não devemos confiar nele para cuidar da nossa coleção de 151 pokémons.

Tenho dois casos para demonstrar que nem sempre a utilização do FOR ALL ENTRIES (trataremos de FAE daqui em diante para economizar letras, pois meu estoque de "L" está baixo) é a mais indicada. Para ambos os exemplos eu fiz duas comparações de tempos, uma com a utilização de FAE e outra sem, sempre usando os mesmos dados.

No primeiro caso, temos a utilização de FAE para grande quantidade de dados. Quando há uma quantidade de dados baixa, o processo de FAE é um processo benéfico que garante acesso único a base de dados, mas quando há uma grande quantidade de dados, a execução do FAE se torna mais lenta que o processo de select individual, pois há mais informação para ser carregada para memória (e quanto maior a carga de dados para a memória, maior a alocação física e menor a performance, progressivamente):


Nesse caso, para o período de 2014, como há poucos registros, a obtenção de dados com FAE é realizada mais rápida, porém, no período de 2011 a obtenção com FAE é mais lenta que um select dentro de um loop. Ok, eu sei que não se usa select dentro de loop, mas quando não há como reduzir a massa de dados ou segmentar o processo, é preferível isso à um DUMP.

No segundo, temos a utilização de FAE derivado de um select sem a utilização de campos chaves (sejam PK, FK ou IDX). Nesse caso a utilização do FAE se torna um pouco maior do que sem o mesmo:


Bom, vale lembrar que para usar o FAE, SEMPRE, repito SEMPRE, deve ser verificado se a tabela de referencia possui conteúdo, pois caso a tabela esteja vazia isso forçará o select a trazer absolutamente todos os registros da tabela acessada..

Caso se interessem, segue abaixo os arquivos dos reports utilizados para medição: fontes.

Até mais e obrigado pelos peixes.

Nenhum comentário:

Postar um comentário