Benilton, bom saber desses pequenos detalhes.
No meu caso, de uns tempos pra cá eu tenho trabalhado com bases de dados da ordem de milhoes de registros e perto de 50 variáveis.
Via de regra, eu faço 99% do "trabalho sujo" (Consistência e transformação das variáveis) usando algum BD SQL (MySQL, Oracle, SQL Server, depende do caso) e após quase tudo arrumado, eu levo pro R.
Com o R em 64 bits, tenho feito alguns testes para ver se faço parte da prepara ção já no R e esses milissegundos a menos tem feito a diferença, principalmente na parte de lidar com memória.
Eu não faço 100% no R porque ainda faço essas transformações com mais rapidez e segurança usando SQL nativo. Um dia (ainda este ano) com certeza o farei com mais naturalidade no R.
lmassis <at> yahoo <dot> com <dot> br
assis.leonard <at> gmail <dot> com
2011/8/11 Benilton Carvalho
<beniltoncarvalho@gmail.com>
A verdade, Leonard, e' que o que "mata" a opcao 1 e' a conversao da
matriz logica is.na(x) para valores *reais* (para que a comparacao com
1 possa ser realizada).
Muitos usuarios sao surpreendidos com os seguintes resultados:
is.double(1) ## TRUE
is.integer(1) ## FALSE
Entao, a expressao
is.na(x) == 1
vai exigir a conversao para numeros reais, que usa mais memoria e
tempo para a conversao...
Agora, se vc tiver o previo conhecimento de que essa substituicao deve
acontecer em apenas uma pequena fracao dos dados, vc pode matar a pau
com:
x[which(is.na(x))] <- .1
Entretanto, e' importante notar que esses ganhos sao substanciais
apenas para conjuntos de dados de grandes volumes ou atividades que
sejam repetidas muitas e muitas vezes. Se for algo a ser executado
apenas uma vez num conjunto de dados pequeno, o que o usuario fara'
com os 3ms que ele economizou?