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 <[email protected]>: > 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 <[email protected]>: >> 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 >> [email protected] >> 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. _______________________________________________ R-br mailing list [email protected] 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.
