Является ли RAWSXP хорошей идеей для хранения больших двоичных объектов?

Question

У меня в основном есть две функции C, которые нужно использовать из R, одна из которых создает какой-то BLOB-объект, а вторая должна его использовать.Хотя пользователь не должен заглядывать внутрь него, я подумал, что было бы разумно не выполнять сериализацию / преобразование в типы R и просто выводить его в RAWSXP.

Есть ли какие-либо неочевидные недостатки этого(т.е. за исключением убийства консоли пользователя при печати)?

РЕДАКТИРОВАТЬ: Хорошо, скажем, например, что у меня есть массив двойных / int64 / (4 x int16) объединений, который является результатом некоторого алгоритма;Я хочу, чтобы он имел нормальную семантику R-копирования, чтобы он вел себя естественно с точки зрения пользователя (таким образом, внешний указатель скорее не является опцией), но я не слишком стремлюсь сериализовать его в R-объекты, поскольку это не будет простым ивероятно, приведет к значительным накладным расходам памяти.

Answer 1

Если большой двоичный объект предполагается сохранить в течение одного сеанса R, то было бы более естественным создать на уровне C внешний указатель и вернуть его пользователю. Это описано в Запись R расширений , в разделе 5.13 .

Одним из ограничений этого подхода является то, что внешний указатель не сериализуется, поэтому не сохраняется на диск или, например, не возвращается из параллельного задания. Это часто подходит, когда большой двоичный объект является ссылкой на структуру данных, которая имеет смысл только в контексте, в котором он был создан (например, дескриптор файла), но в меньшей степени, если это статическая структура данных. В этом случае может быть уместным сохранение данных в виде RAWSXP, как правило, в виде слота или элемента класса S3 или S4 с методами print / show, чтобы скрыть подробности от пользователя. Возможно, недостатком является то, что RAWSXP выделяется и управляется R, например, при условии сбора мусора, тогда как содержимое внешнего указателя, вероятно, будет распределяться более напрямую через Calloc и Free.

Answer 2

Как указали Мартин и Джош, внешние указатели могут быть предпочтительнее.

Ваш подход звучит так, как, например, bigmemory : он выделяет кусок памяти , откладывает R и контролирует его, тем самым обходя управление памятью и ограничения R.Для ваших целей не имеет значения, что bigmemory использует это для передачи памяти обратно в R как пользовательский тип данных - внешний указатель делает это возможным.Другими пакетами, использующими внешние указатели, являются RODBC для объекта подключения к базе данных и мой RcppDE пакет, который делает то, что делает DEoptim , но на C ++ и, таким образом, позволяет пользователю скомпилированные функции in для оптимизации, используя оболочку Rcpp для внешних указателей: класс Rcpp::XPtr.

И, как справедливо говорит Мартинг, все это вхорошее руководство.