[firebase-br] rotina numa procedure contendo um while eleva o uso da cpu para 100%

Gladiston Santana gladiston em vidy.com.br
Qua Maio 8 16:33:05 -03 2013


A quantidade de dias uteis para cada colaborador é bem peculiar, cada um
deles tem uma tabela privativa e outra global (vale para todos os
colaboradores), assim eu tenho de saber o colaborador e a data e a
procedure apenas me retorna true ou false, nessa eu não perco tempo.
O loop é o caso onde tenho de testar cada dia da semana, por que há os que
trabalham sabado/domingo e outros que não trabalham na segunda (sortudos),
por isso não tenho uma lógica para trabalhar por grupos de dias.

Mas o principal mesmo é ter uma função que faça a cpu respirar enquanto o
calculo não é concluído, veja que não tem nada aqui tão desesperador,
apenas me preocupo que dados de entrada não façam o while se estender e
alguem achar que o micro parou.


Gladiston Santana
Departamento de TI
Grupo Vidy
Tel (11) 4787-3122 ramal 228
Rod. Régis Bittencourt 3360 - Km 272,5
Taboão da Serra - SP - CEP: 06793-000
Visite nosso site: www.vidy.com.br
Visite também : www.expolabor.com.br




Em 8 de maio de 2013 15:45, Sandro Souza <escovadordebits em gmail.com>escreveu:

> Bom dia/tarde Gladiston.
>
> Meu nobre amigo, acredito que não haja tal recurso no Firebird, o que
> viria muito a calhar nessa situação.
>
> Acredito que a única saída, nesse cenário, seria tentar ver alguma
> forma de otimizar o código dessas stored procedures.
>
> Pelo que pude entender, a stored procedure selecionável
> "get_se_dia_util" recebe o ID/código de um colaborador e uma data,
> retornando apenas a informação do dia ser (S) ou não (N) um dia útil.
>
> Será que não seria viável criar uma outra stored procedure que retorne
> a quantidade de dias úteis dentro de uma semana, de acordo com o
> colaborador? Nesse caso, dependendo do período, poderia até quebrar o
> período em semanas, o que aceleraria todo o processo, e o que sobrar,
> deixa no processamento de dia a dia.
>
> A mesma lógica poderia ser utilizada para os meses, ou seja, criar uma
> outra stored procedure selecionável que retornasse a quantidade de
> dias úteis de um mês para o colaborador informado, e aí você poderia
> quebrar o período em meses, caso o período fosse grande o suficiente.
>
> São apenas sugestões de como poderia acelerar esse processamento, e
> reduzir a quantidade de iterações desse laço.
>
> Dividir para conquistar. :D
>
> Espero ter ajudado mais que atrapalhado. :D
>
> Em 08/05/13, Gladiston Santana<gladiston em vidy.com.br> escreveu:
> > Tenho uma rotina numa procedure que contem um while, em parte é assim :
> >
> >   while (l_dias_uteis < p_qtde_dias) do
> >   begin
> >     l_temp_date=dateadd(1 day to :p_dt_inicio);
> >     select dia_util from get_se_dia_util(:p_id_colaborador, :l_temp_date)
> > into :l_se_util;
> >     if (:l_se_util='S') then l_dias_uteis=:l_dias_uteis+1;
> >   end
> >
> > Funciona bem, contudo quando há períodos maiores onde o while terá também
> > um tempo maior de processamento noto que o % de uso da CPU sobe para 99 e
> > 100% enquanto o while ocorre.
> >
> > Eu gostaria de saber dos nobres colegas se há alguma função no FB ao
> estilo
> > "Application.ProcessMessages" para desafogar esse ciclo de CPU. Procurei
> no
> > manual, mas não achei nenhum.
> >
> > Numa aplicação embarcada que estou criando, esse problema é bem notório e
> > já cogito re-escrever essa rotina no lado da aplicação.
> >
> > Enfim, qualquer ajuda é bem vinda.
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> > http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
>



Mais detalhes sobre a lista de discussão lista