[R-br] Alteração em função de pacote (novo tópico)

Benilton Carvalho beniltoncarvalho em gmail.com
Quinta Maio 31 21:00:01 BRT 2012


Para ser sincero, minha impressao e' q vc esta' procurando problema
onde nao existe (eu ficaria surpreso se um pacote escrito pelo B
Ripley - que e' um dos chefoes de desenvolvimento do R - apresentasse
problemas de eficiencia).

De qualquer forma, coloquei um computador lentinho aqui do lado para
executar o codigo que vc passou, vindo do exemplo da funcao  a q vc se
refere... Ao inves de num.sim=1000, eu usei num.sim=10000 .
Adicionalmente, usei o metodo de perfilacao de funcoes (que imagino
que vc tenha usado antes de iniciar essa busca por pontos de lentidao
no codigo)...

A parte essencial alterada do codigo que vc enviou ficou assim:

Rprof('geoComp.Rprof')
preditos.simu <- volta.cokri(md.cov.ck,num.simu=10000,int.conf=0.95)
Rprof(NULL)
theProf <- summaryRprof('geoComp.Rprof')

Dai' preste atencao no self.time do data.frame a seguir:

theProf$by.total

observe que 71% do tempo e' gasto com o comando "data.frame" e  23% do
tempo usado por "unlist"... (ou seja, nenhum dos seus "candidatos")...
isso sugere, na verdade, que internamente na funcao volta.cokri(), e'
bem provavel que essas funcoes deveriam ser aplicadas mais
cuidadosamente (possivelmente estao sendo chamadas frequentemente ou
de modo desnecessario)...

Essas duas informacoes me fazem pensar em olhar o conteudo de
volta.cokri() e, como predito, a funcao comeca com:

    compos1 <- data.frame(matrix(nrow = nlinhas/2, ncol = 3))
    compos <- data.frame(matrix(nrow = nlinhas/2, ncol = 3))

logo em seguida, vc tem um for() que usa

        compos1 <- cbind(compos, compos1)

(isso e' a coisa que mais afeta desempenho - crescer um objeto de
forma inadequada)

Dai', eu usaria o q foi possivelmente a primeira sugestao que te dei
quando vc primeiro perguntou a esse respeito: a sugestao era 1)
identifique os loops; 2) substitua-os por algo como mclapply()... Dito
isso, a funcao ficaria como mostro no Gist a seguir (tudo que fiz foi
trocar o for() por mclapply() e combinar o resultado final de uma vez
so):

https://gist.github.com/2847337

Feito isso, usando a funcao original, numa tarefa que durava 33
segundos, usando a funcao que modifiquei executa a mesma tarefa em 4
segundos, segundo mostrado abaixo:

> system.time(preditos.simu <- volta.cokri(md.cov.ck,num.simu=3000,int.conf=0.95))
   user  system elapsed
 32.142   0.689  32.831
> system.time(preditos.simu <- volta.cokri2(md.cov.ck,num.simu=3000,int.conf=0.95))
Loading required package: parallel
   user  system elapsed
  3.476   0.120   3.646

b

2012/5/31 Junior Beleti <beleti.junior em gmail.com>:
> Olá Benilton, tentando explicar melhor meu problema:
>
> Faço uso de um pacote chamada geoComp. Tal pacote é utilizado de forma geral
> para modelar o padrão espacial
> de dados composicionais. Foi um trabalho da professora Ana Beatriz.
>
> O problema está quanto ao tempo de processamento para realizar o trabalho
> necessário.
>
> Analisando mais a fundo, verifiquei que o maior problema quanto a desempenho
> está na função "volta.cokri" desse pacote.
> Nessa função existe uma chamada à função "mvrnorm" e é justamente nessa
> chamada que ocorre o maior problema de desempenho.
>
> Verifiquei também que na função "mvrnorm" existe uma chamada para a tal
> função "eigen", que se trata de um código-objeto fortran.
>
> Inicialmente utilizei a função "mclapply" para tentar melhorar tal
> desempenho, mas não obtive muito sucesso. O que estava pensando quando
> insisti na ideia de criar a nova função no pacote base, foi o de que se
> chamando funções "diferentes", ou seja, criando funções idênticas
> cada uma com o espaço de endereçamento e nomes diferentes, poderia aumentar
> o desempenho.
>
> A seguir, está um script utilizado:
>
> require(geoComp)
> require(MASS)
> require(statmod)
> require(geoR)
> data(pivo)
> dados <- pivo[,c(6,7,8,1,2)]
> dados <- as.geoComp(dados)
> bor <- cbind(c(0,seq(0,200,l=100),0),c(0,sqrt(200^2-seq(0,200,l=100)^2),0))
> ## bor é uma matriz 2x102
> estima <- mec(dados)
> gr <- pred_grid(bor, by=4)
> md.cov.ck <- cokrigagem(estima[[1]]$Estimativas, loc=gr,dados.comp=dados)
> preditos.gh <- volta.quad(md.cov.ck,n.pontos=7,Variancia=FALSE)
> preditos.gh <- data.frame(preditos.gh)
> write.table(preditos.gh,"pred_by4k7ns1000MBM.txt")
> preditos.simu <- volta.cokri(md.cov.ck,num.simu=1000,int.conf=0.95)
> preditos.simu <- data.frame(preditos.simu[[1]])
> preditos.simu.ic <- data.frame(preditos.simu[[2]])
> write.table(preditos.simu,"predsimu_by4k7ns1000MBM.txt")
> write.table(preditos.simu.ic,"predsimuic_by4k7ns1000MBM.txt")
>
> O pacote geoComp pode ser adquirido no endereço:
> (http://www.din.uem.br/~pg45178/geocomp/geoComp.tar.gz)
>
> Um resumo do trabalho pode ser encontrado em:
> (http://www.leg.ufpr.br/lib/exe/fetch.php/pessoais:abtmartins:rbb09_2.pdf)
>
> Obrigado pela atenção.
>
> Carlos.
>
> _______________________________________________
> R-br mailing list
> R-br em listas.c3sl.ufpr.br
> https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br
> Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código
> mínimo reproduzível.


Mais detalhes sobre a lista de discussão R-br