Сравнение скоростей способов доступа к CoreArray - lanit-tercom-school/analyzeme GitHub Wiki
Скорости выполнения бенчмарка при использовании связей (бенчмарк ниже):
Связь 1 (Java->GDSFormat): 0.006 - 0.008
Связь 2 (Java->Gdsfmt): 0.035 - 0.042
Связь 3 (C++->GDSFormat): 0.006 - 0.007
Связь 4 (R->Gdsfmt): 0.009 - 0.01
Зеленым цветом указан язык, на котором реализована библиотека.
Стрелка значит "A использует библиотеку B (через мост / напрямую)"
Из картинки видно, что так или иначе придется ссылаться на CoreArray, других библиотек нет.
У CoreArray есть две обертки, написанные автором- GDSFormat и gdsfmt.
GWASTools просто ссылается на gdsfmt, он включен в схему, потому что имеет много возможностей для конвертации GDS в другие форматы.
Для связи 1 (Java->GDSFormat) используется JNI, так как JNA гораздо медленнее.
Для связи 2 используется Rserve. (rJava плохо задокументирована и странно работает).
Бенчмарк (на Rserve/GDSFormat/JNI-GDSFormat код делает аналогичные вещи):
library(gdsfmt)
library(tictoc)
t<-as.numeric(Sys.time())
invisible((genofile <- openfn.gds("1000gen.gds")))
invisible((g <- read.gdsn(index.gdsn(genofile, "snp.position"), start=c(1), count=c(200000))))
closefn.gds(genofile);
print(as.numeric(Sys.time())-t,digits = 3)
Комментарий к бенчмарку:
Надо понимать, что бенчмарк показывает скорость передачи и конвертации большого массива данных (причем одномерного массива, при более сложной структуре данных результаты могут измениться), что далеко не всегда важный показатель. Вызов какой-нибудь одной функции(все действие происходит в c) и возврат одного простого элемента (типа числа) в джаву при любой связи будет происходить быстро.
Напоследок, нарезка скринов с результатами запусков:
https://github.com/lanit-tercom-school/analyzeme/blob/dev/wiki/images/speed_comparison.png