Ускорить загрузку RData
Я проверил несколько связанных вопросов, таких как
Как быстро загрузить данные в R?
Я цитирую определенную часть самого рейтингового ответа
Это зависит от того, что вы хотите сделать и как вы обрабатываете данные дальше. В любом случае загрузка из двоичного объекта R всегда будет быстрее, если вам всегда нужен один и тот же набор данных. предельная скорость здесь - скорость вашего жесткого диска, а не R. Бинарная форма является внутренним представлением кадра данных в рабочей области, поэтому больше не требуется преобразование
Я действительно думал об этом. Однако жизнь - это эксперимент. У меня есть файл 1.22 ГБ, содержащий объект igraph. Тем не менее, я не думаю, что то, что я нашел здесь, связано с классом объекта, в основном потому, что вы можете загрузить ('file.RData') даже до того, как вы вызовете "library".
Диски на этом сервере довольно крутые. Как вы можете проверить время чтения в памяти
[email protected] data$ pv mygraph.RData > /dev/null
1.22GB 0:00:03 [ 384MB/s] [==================================>] 100% `
Однако, когда я загружаю эти данные из R
>system.time(load('mygraph.RData'))
user system elapsed
178.533 16.490 202.662
Таким образом, загрузка файлов *.RData в 60 раз медленнее, чем ограничения на диске, что должно означать, что R действительно делает что-то во время "загрузки".
У меня такое же чувство, когда я использовал разные версии R с различным оборудованием, на этот раз я получил терпение, чтобы провести бенчмаркинг (в основном потому, что с таким прохладным дисковым хранилищем было ужасно, сколько времени действительно занимает загрузка)
Любые идеи о том, как преодолеть это?
После идей в ответах
save(g,file="test.RData",compress=F)
Теперь файл равен 3,1 ГБ против 1,22 ГБ. В моем случае загрузка uncompress немного быстрее (диск не является моим узким местом).
> system.time(load('test.RData'))
user system elapsed
126.254 2.701 128.974
Чтение несжатого файла в память занимает 12 секунд, поэтому я подтверждаю, что время, затрачиваемое на настройку среды
Я вернусь с результатами RDS, звучит как интересно
Здесь мы, как обещали
system.time(saveRDS(g,file="test2.RData",compress=F))
user system elapsed
7.714 2.820 18.112
И я получаю 3,1 ГБ, как "save" uncompressed, хотя md5sum отличается, вероятно, потому, что save также сохраняет имя объекта
Теперь читаем...
> system.time(a<-readRDS('test2.RData'))
user system elapsed
41.902 2.166 44.077
Таким образом, объединение идей (uncompress и RDS) выполняется в 5 раз быстрее. Спасибо за ваш вклад!
Ответы
Ответ 1
save сжимается по умолчанию, поэтому требуется дополнительное время для распаковки файла. Затем для загрузки большего файла в память требуется немного больше времени. Ваш пример pv - это просто копирование сжатых данных в память, что не очень полезно для вас.; -)
UPDATE:
Я опробовал свою теорию, и она была неправильной (по крайней мере, на моей машине с Windows XP с процессором 3,3 ГГц и жестким диском 7200 об/мин). Загрузка сжатых файлов происходит быстрее (вероятно, потому, что он уменьшает дисковый ввод-вывод).
Дополнительное время тратится на RestoreToEnv (в saveload.c) и/или R_Unserialize (в serialize.c). Таким образом, вы можете ускорить загрузку, изменив эти файлы, или, возможно, используя saveRDS для индивидуального сохранения объектов в myGraph.RData, а затем используя loadRDS для нескольких процессов R для загрузки данных в общую память...
Ответ 2
Для больших переменных, я подозреваю, что большую часть времени занимает внутренний код C (http://svn.r-project.org/R/trunk/src/main/saveload.c). Вы можете запустить профилирование, чтобы убедиться, что я прав. (Весь код R в функции load выполняет проверку того, что ваш файл не пуст и не был поврежден.
Помимо чтения переменных в память, они (среди прочего) должны храниться внутри среды R.
Единственным очевидным способом получения большого ускорения при загрузке переменных было бы переписать код параллельно, чтобы обеспечить одновременную загрузку переменных. Это, по-видимому, требует существенной перезаписи внутренних элементов R, поэтому не задерживайте дыхание для такой функции.
