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@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@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.

Junior Até onde sei o geoComp nao foi escrito com cuidado para eficiencia em R (até por isto não está no CRAN!!). A preocupação da autora no momento da escrita era apenas de implementar como protótipo um método desenvolvido. Portanto é muito bem vinda a sua atuação para melhorar o código! Entretanto eu nao mexeria em NADA compilado até ter certeza que rtudo que pudesse ser feito em termos de programação em R mesmo fosse implementado (manipila;ção de objetos, ordenação de operação, formas mais eficientes de efetuar operacoes) etc neste caso "o buraco é mais em cima" On Thu, 31 May 2012, Junior Beleti wrote:

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.