> It will of necessity be slower (because there's more machinery underlying > the sqldf package); but I doubt whether it would be noticeably slower than > the native R solution in most practical situations. The same would be true > for plyR's implementation (it relies on the proto package, which slows > things down a bit).
Plyr doesn't use proto at all (that's ggplot2). Plyr is generally faster than split + lapply etc for large datasets with many splits, but slower with smaller datasets/fewer splits. > The point is that the most important issue in almost all cases is the > programmer's time to create and debug correct code, especially as the native > machine speeds continue to increase. R gives you the option to choose > whatever idiom you prefer to minimize this. The software implementation > differences thereafter will rarely be important. Totally agreed! In my mind the advantage of learning plyr, is that you learn one set of methods that work for lists, data frames and arrays. And because all of the functions are designed with consistency in mind, it hopefully takes less time to learn them all. Hadley -- http://had.co.nz/ ______________________________________________ R-help@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.
