slow dget

dput/dget were not intended to save/restore large objects.  Understand
what is happening in the use of dput/dget.  dput is creating a text
file that can reconstitute the object with dget.  dget is having to
read the file in and then parse it:

dget

function (file)
eval(parse(file = file))
<environment: namespace:base>

This can be a complex process if there object is large and complex.

save/load basically take the binary object and save it with little
additional processing and the load is just as fast.

In general, most of the functions can be used both correctly and
incorrectly.  So should a warning for every potential
condition/criteria be put in the help file?  Probably not.  It is hard
to protect the user against him/herself.

So what you are doing in seeing how long alternatives take is a good
learning tool and will help you improve your use of the features.

I have a data structure that is fast to dput(), but very slow to dget(). On
disk, the file is about 35MB.

system.time(dget("r.txt"))

? user ?system elapsed
?142.93 ? ?1.27 ?192.84

The same data structure is fast to save() and fast to load(). The .RData file on
disk is about 12MB.

system.time(load("r.RData"))

? user ?system elapsed
? 4.89 ? ?0.08 ? ?7.82

I imagine that this is a known speed issue with dget, and that the recommended
solution is to use load, which is fine with me. If so, perhaps a note to this
effect could be added to the dget help page.

All timings above using

R version 2.12.0 (2010-10-15)
Platform: i386-pc-mingw32/i386 (32-bit)

______________________________________________
R-help at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Jim Holtman
Cincinnati, OH
+1 513 646 9390

What is the problem that you are trying to solve?