Essa é a uma tradução do artigo original de Adriano Fernandes
Aqui temos uma dica simples e rápida que pode deixar seu código PSQL mais rápido!
Abaixo temos uma versão "lenta" de um código de exemplo:
create or alter procedure p1 (i1 integer)
as
begin
while (i1 > 0) do
i1 = i1 - 1;
end
execute procedure p1(10000000)
Na minha máquina, essa rotina leva cerca de 3.2 segundos para executar no Firebird 4.
Abaixo temos a versão da rotina em BLR (Binary Language Representation):
blr_version5,
blr_begin,
blr_message, 0, 2,0,
blr_long, 0,
blr_short, 0,
blr_message, 1, 1,0,
blr_short, 0,
blr_receive, 0,
blr_begin,
blr_stall,
blr_label, 0,
blr_begin,
blr_begin,
blr_label, 1,
blr_loop,
blr_begin,
blr_if,
blr_gtr,
blr_parameter2, 0, 0,0, 1,0,
blr_literal, blr_long, 0, 0,0,0,0,
blr_assignment,
blr_subtract,
blr_parameter2, 0, 0,0, 1,0,
blr_literal, blr_long, 0, 1,0,0,0,
blr_parameter2, 0, 0,0, 1,0,
blr_leave, 1,
blr_end,
blr_end,
blr_end,
blr_end,
blr_send, 1,
blr_begin,
blr_assignment,
blr_literal, blr_short, 0, 0,0,
blr_parameter, 1, 0,0,
blr_end,
blr_end,
blr_eoc
A parte importante desse código é o uso de blr_parameter2 dentro do blr_loop. Internamente, blr_parameter2 tem dois "slots" internos, um para o valor e outro para um flag de indicação de nulo. Sendo assim, total vez que o parâmetro é lido ou gravado, dois slots são acessados, sendo que a forma de acessar o slot de indicação de nulo não é otimizada. É como um acesso de alto nível usando níveis mais baixos como blocos de construção. É claro que isso pode ser melhorado em futuras versões.
Já as variáveis têm um único slot para ambas as informações! Sabendo disso, podemos alterar o código para:
create or alter procedure p2 (i1 integer)
as
declare variable v1 integer;
begin
v1 = i1;
while (v1 > 0) do
v1 = v1 - 1;
end
execute procedure p2(10000000)
Apesar de em um primeiro momento o código parecer mais lento pois foi adicionada uma linha inicializando a variável com o valor do parâmetro, no fim das contas, ele acaba sendo mais rápido pois o acesso à variáveis é mais rápido do que aos parâmetros.
Na minha máquina, o código é executado em 2.3 segundos.
Vejamos sua representação em BLR:
blr_version5,
blr_begin,
blr_message, 0, 2,0,
blr_long, 0,
blr_short, 0,
blr_message, 1, 1,0,
blr_short, 0,
blr_receive, 0,
blr_begin,
blr_declare, 0,0, blr_long, 0,
blr_assignment,
blr_null,
blr_variable, 0,0,
blr_stall,
blr_label, 0,
blr_begin,
blr_begin,
blr_assignment,
blr_parameter2, 0, 0,0, 1,0,
blr_variable, 0,0,
blr_label, 1,
blr_loop,
blr_begin,
blr_if,
blr_gtr,
blr_variable, 0,0,
blr_literal, blr_long, 0, 0,0,0,0,
blr_assignment,
blr_subtract,
blr_variable, 0,0,
blr_literal, blr_long, 0, 1,0,0,0,
blr_variable, 0,0,
blr_leave, 1,
blr_end,
blr_end,
blr_end,
blr_end,
blr_send, 1,
blr_begin,
blr_assignment,
blr_literal, blr_short, 0, 0,0,
blr_parameter, 1, 0,0,
blr_end,
blr_end,
blr_eoc
Nele, blr_parameter2 é acessado uma única vez (antes do blr_loop) e a variável blr_variable é usada dentro do loop.
Atenção: Essa "gambiarra" não é necessária em códigos EXECUTE BLOCK, pois o Firebird faz isso automaticamente no código BLR gerado.
Se você está se perguntando porque ele não faz isso automaticamente também em stored procedures/triggers, a resposta é que códigos simples (que não acessa os parâmetros milhares de vezes) ficariam um pouco mais lentos, e caso a rotina fosse executada muitas vezes, refletiria em uma queda de performance.
