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.
On Fri, Nov 5, 2010 at 11:16 PM, Jack Tanner <ihok at hotmail.com>
wrote:> 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?