Demora na execução

[mcsmagngo]

Olá! Tudo bem? Tenho enfrentado um problema com a demora na execução de download. Fiquei mais de 24 horas com o código sendo executado e não chegou nem aos 15%. Não é problema de internet e nem computador. Pode me ajudar, por favor? Usei esse código de execução:

devtools::install_github("danicat/read.dbc") remotes::install_github("rfsaldanha/microdatasus")

library(microdatasus)

cnes_profissioanais <- fetch_datasus(information_system = "CNES-PF", year_start = 2008, year_end = 2022, month_start = 8, month_end = 8, uf = "all")

Grato desde já!

[gustavoalcantara]

@rfsaldanha desculpa a intromissão aqui. Mas vou tentar colaborar. @mcsmagngo Não acha melhor particionar por UF/ano/mes?

[rfsaldanha]

Olá @gustavoalcantara . Eu que agradeço, ajuda da comunidade é sempre bem-vinda.

@mcsmagngo tente fazer o download de um período menor ou mesmo apenas um mês e veja se a velocidade de download está muito lenta.

[rafapereirabr]

Oi pessoal. Analise o codigo com calma e cheguei a seguinte conclsusão:

diagnostico

• o download do dado é rápido
• a descompactaçao do dado de .dbc para .dbf, feita pelo pacote {read.dbc}, também é rápida.
• a causa da demora na execução é que na hora de ler o dado para memória, a função read.dbc() chama a função foreign::read.dbf() que tem como comportamento default tentar detectar a classe de cada coluna. E isso é que que causa a demora.

Solução final:

Ao invés de chamar :

• partial <- read.dbc::read.dbc(temp) O microdatasus poderia chamar:
• partial <- read.dbc::read.dbc(temp, as.is = TRUE )

O próximo passo é só alterar as classes das colunas

# update to appropriate column classes
partial <- utils::type.convert(partial , as.is = TRUE )

Ao usar as.is = TRUE, a função lê todas coluna como character, o que fica muuuito mais rapido. A leituda de uma base de profissionais de saúde (PFMS2305.dbc) demorou 523.19 com comportamento padrão, e apenas 0.64 com parâmetro as.is = TRUE.

[rafapereirabr]

eu vou implementar isso na versão forked to pacote porque preciso de resolver isso com certa urgencia. Se quiserem, eu posso abrir um PR depois.

[rfsaldanha]

Obrigado Rafael! Vou tentar fazer por aqui.

[rafapereirabr]

Ok, Rafa! sem problema. Se voce não concordar com column class sugeria pelo utils::type.convert, é facil tabem incluir umas linhas que fazem a conversao das classes de maneira hard coded. Ainda sim isso fica muuutio mais rapido

[rfsaldanha]

Tranquilo! Vou ver como fazer, pois isso vai afetar as transformações de todas as funções process_* , algun passos esperam como fator, numérico, character etc.

Pode ser o momento de arrumar isso e implementar o data.table em todas as funções.

[rafapereirabr]

olha, a diferença de tempo de processamento é brutal. Eu estava demorando praticamente 24 horas para baixar as bases de pessoa fisica para um unico mês/ano de todos estados. Agora eu demoro 5 minutos.

[rfsaldanha]

Faz todo o sentido. Eu era muito "garoto" quando fiz essa função rsrs

[rafapereirabr]

sei como é! rsrsrs O geobr tambem tem muitas coisas que hoje eu teria feito diferente rsrsrsr

[rfsaldanha]

@rafapereirabr talvez isso te ajude, aqui tem o CNES como um índice do ES que você pode acessar. Também trabalho nesse projeto.

https://pcdas.icict.fiocruz.br/conjunto-de-dados/cadastro-nacional-de-estabelecimentos-de-saude/

[oranzani]

Oi @rfsaldanha, isso resolveria aquela outra issue que abri há um tempo atrás pelo formato #53 . Obrigado man!

[rfsaldanha]

Pessoal! Terminei os testes e coloquei no main a versão com as.is = TRUE. Obrigado pela ajuda de todos!

[patrulhasirius]

Desculpe pelo necrobump, mas eu havia encontrado esse problema um tempo atrás e resolvi com um repositório próprio em rust bem simples que permite que seja feita apenas a leitura das colunas especificadas do dbf, tendo grandes ganhos de performance.

Seria possível implementar esta lógica por meio de um módulo do extendr e tirar a dependência do read.dbc. Eu tinha pensado nessa posibilidade no passado, mas a interação do R com o rust não era tão boa e não era possivel executar a parte mais lenta do algorítimo em mútiplas threads.

Caso seja de interesse posso criar um patch, porém me questiono se o uso do extendr não poderia afetar a aprovação no CRAN.