Há pouco tempo, um novo cliente adquiriu o nosso sistema, e para eles é bastante comum realizar operações de transporte com centenas de notas fiscais embarcadas - eles transportam para uma loja virtual bastante popular.
Ao realizar estas operações, foi notado um problema de velocidade muito grande, e descobrimos que o responsável por isso era o ACBr, mais especificamente em uma determinada linha da função LerXml do pcteCTeR.pas.
Conseguimos resolver este problema, e gostaríamos de compartilhar a solução com vocês.
O "culpado" por este problema de velocidade é a repetição da função Leitor.rExtrai, que é executada a cada documento vinculado. Para documentos pequenos, não há diferença significativa de desempenho, mas à medida que a quantidade de documentos aumenta, mais pesada fica a busca.
A solução foi eliminarmos esta repetição - que tinha como objetivo apenas identificar se ainda haviam documentos vinculados - e criar uma função que apenas retorna a quantidade de repetições necessária.
Isso fez com que a velocidade de carregamento caísse de vários minutos para apenas poucos segundos.
Além da alteração na unit pcteCTeR.pas, foi necessário alterar a unit pcnLeitor.pas, criando uma propriedade para permitir definir o Nivel após a atribuição do Grupo. As duas units modificadas estão em anexo, e correspondem a revisão 11941 do Trunk2.
Em anexo também um exemplo de CT-e emitido pelo nosso cliente, com 1994 NF-e's vinculadas (a operação original era composta de 5980 NF-e's, que precisou ser dividido em três devido a limitação da SEFAZ de 2000 documentos). O conteúdo foi modificado para preservar as informações da transportadora e do seu cliente, mas o arquivo carrega normalmente no ACBr.
Não utilizamos a regra de indentação do ACBr, mas sintam-se à vontade em padronizar de acordo com seus critérios.
Após substituir os dois arquivos, é necessário recompilar os pacotes ACBr_PCNComum e ACBr_CTe.
CTeGigante.xml
pcnLeitor.pas
pcteCTeR.pas
