Сравнение скоростей способов доступа к CoreArray

Скорости выполнения бенчмарка при использовании связей (бенчмарк ниже):
Связь 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) и возврат одного простого элемента (типа числа) в джаву при любой связи будет происходить быстро.

Напоследок, нарезка скринов с результатами запусков: