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

[Benilton Carvalho]

A titulo de curiosidade... o 'timing' para 10 mil simulacoes...

> system.time(preditos.simu <- volta.cokri(md.cov.ck,num.simu=10000,int.conf=0.95))
   user  system elapsed
653.044   5.373 658.428
> system.time(preditos.simu <- volta.cokri2(md.cov.ck,num.simu=10000,int.conf=0.95))
   user  system elapsed
  4.185   0.186  11.843


b

2012/6/1 Benilton Carvalho <beniltoncarvalho em gmail.com>:
> 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.