... помимо того, что Rscript вызывается с #!/usr/bin/env Rscript
и littler с #!/usr/local/bin/r
(в моей системе) в первой строке файла сценария. Я нашел определенные различия в скорости выполнения (кажется, что littler немного медленнее).
Я создал два фиктивных сценария, выполнил каждого 1000 раз и сравнил среднее время выполнения.
Вот файл Rscript:
#!/usr/bin/env Rscript
btime <- proc.time()
x <- rnorm(100)
print(x)
print(plot(x))
etime <- proc.time()
tm <- etime - btime
sink(file = "rscript.r.out", append = TRUE)
cat(paste(tm[1:3], collapse = ";"), "\n")
sink()
print(tm)
и вот littler файл:
#!/usr/local/bin/r
btime <- proc.time()
x <- rnorm(100)
print(x)
print(plot(x))
etime <- proc.time()
tm <- etime - btime
sink(file = "little.r.out", append = TRUE)
cat(paste(tm[1:3], collapse = ";"), "\n")
sink()
print(tm)
Как Вы видите, они почти идентичны (первая строка, и снизьтесь, аргумент файла отличаются). Вывод sink
редактор к текстовому файлу, следовательно импортированному в R с read.table
. Я создал сценарий удара для выполнения каждого сценария 1000 времена, затем вычисленные средние числа.
Вот сценарий удара:
for i in `seq 1000`
do
./$1
echo "####################"
echo "Iteration #$i"
echo "####################"
done
И результаты:
# littler script
> mean(lit)
user system elapsed
0.489327 0.035458 0.588647
> sapply(lit, median)
L1 L2 L3
0.490 0.036 0.609
# Rscript
> mean(rsc)
user system elapsed
0.219334 0.008042 0.274017
> sapply(rsc, median)
R1 R2 R3
0.220 0.007 0.258
Длинная короткая история: около (очевидного) различия времени выполнения, там некоторое другое различие? Более важный вопрос: почему необходимо предпочесть littler по Rscript (или наоборот)?
Пара небольших комментариев:
Путь /usr/local/bin/r
произвольный, вы можете использовать /usr/bin/env r
, как мы и делаем в некоторых примерах. Насколько я помню, это ограничивает другие аргументы, которые вы можете дать r
, поскольку он принимает только один, когда вызывается через env
Я не понимаю ваш эталон, и почему вы делаете это таким образом. У нас есть сравнения по времени в исходниках, см. tests/timing.sh
и tests/timing2.sh
. Возможно, вы хотите разделить тест между запуском и созданием графика, или что-то еще.
Всякий раз, когда мы запускали эти тесты, побеждал littler. (Он все еще побеждал, когда я повторно запускал их сейчас.) Это имело смысл для нас, потому что если вы посмотрите на исходные тексты Rscript.exe
, он работает по-другому, устанавливая окружение и командную строку перед тем, как вызвать execv(cmd, av)
. littler может запускаться немного быстрее.
Главная цена - портативность. В том виде, в котором построен littler, он не доберется до Windows. Или, по крайней мере, не легко. Тем не менее, у нас есть портированный RInside, так что если кто-то действительно захочет...
Littler появился впервые в сентябре 2006 года в сравнении с Rscript, который появился с R 2.5.0 в апреле 2007 года.
Rscript теперь везде, где есть R. Это большое преимущество.
Опции командной строки немного более разумны для littler, на мой взгляд.
Оба работают с CRAN-пакетами getopt и optparse для разбора опций.
Так что это личное предпочтение. Я был соавтором littler, многому научился, делая это (например, для RInside), и до сих пор нахожу его полезным - так что я использую его десятки раз каждый день. Он управляет CRANberries. С ним работает cran2deb. Ваш пробег может, как говорится, варьироваться.
Отказ от ответственности: littler - один из моих проектов.
Postscriptum: Я бы написал тест как
Я бы написал это как
fun <- function { X <- rnorm(100); print(x); print(plot(x)) }
replicate(N, system.time( fun )["elapsed"])
или даже
mean( replicate(N, system.time(fun)["elapsed"]), trim=0.05)
чтобы избавиться от выбросов. Более того, вы только по существу измеряете ввод/вывод (печать и график), которые оба получат из библиотеки R, так что я бы ожидал небольшой разницы.