Джонатан, глубоко анализируя ваш случай, ответ на ваши проблемы с производительностью зависит от множества факторов. Позвольте мне объяснить их один за другим:
- Бокс / Распаковка - действительно, это повлияло на ваши результаты, как ответили в этой теме Как избежать автоматической блокировки примитивов в массивах в javonet есть бета-версия, которая включает в себя возможность заставить Javonet использовать примитивные массивы в качестве результата. Так что эта проблема может быть легко решена.
- Пропущены ненужные строки , как упомянуто здесь Производительность Javonet В текущем выпуске Javonet для разработчиков Java по-прежнему существует проблема, из-за которой даже при оптимизированных последующих вызовах методов имя метода передавалось Сторона .NET и преобразована в строку .NET. Более того, для каждого результата имя типа возвращалось и преобразовывалось в строку Java. Это уже решено в Javonet для разработчиков .NET. Мы решили эту проблему для вас во временной сборке, объединив эти оптимизации в Javonet для разработчиков Java. (ссылка ниже).
- Преобразование типов данных Анализируя ваши результаты, мы обнаружили проблему в «двойной» обработке, которая могла повлиять на вашу производительность. Это также рассматривается во временной сборке, указанной ниже.
- Тип операции для Javonet самой дорогой операцией является преобразование типов значений на лету. В зависимости от времени он либо сверхбыстрый (т.е. логический), либо довольно дорогой (то есть UInt64). Таким образом, ваш случай особенный, поскольку вы делаете несколько межграничных вызовов, но вы делаете много преобразования типа значения (2 ГБ массива). Совершенно разные результаты вы должны наблюдать, если сравниваете многократно вызываемый (то есть 250 тыс.) Метод, генерирующий простое число для растущего аргумента "x" (если вы сравните это с вызовом того же метода через веб-сервисы, я буду в 1000 раз быстрее)
- Способ сравнения результатов Наконец, но очень важно, что производительность Javonet варьируется в зависимости от выполняемой вами операции и способа сравнения результатов. Понятно, что если вы вызываете метод, который ничего не делает чисто в .NET, он будет оптимизирован компилятором и будет выполнен почти "без времени". Когда вы вызываете его через Javonet, потребуется некоторое «крошечное» время (т. Е. 0,0000009 с), чтобы передать вызов .NET. В результате, когда вы делите «крошечный» на «нет времени», это все равно, что делить 10 на 0, чтобы вы могли предположить, что он бесконечно медленнее (означает ли это, что Javonet работает медленно? - не совсем). Однако, если вы вызываете метод, который выполняет некоторую обработку или извлекает данные из БД и т. Д.
Нестабильная бета-версия с исправлением ошибки обмена строк и двойного преобразования типов данных:
... ссылка удалена из-за более новой версии, включенной в обновление ниже ...
Пожалуйста, используйте это только для целей измерения. Мы будем рады узнать ваши результаты. Вскоре эти изменения будут переведены в стабильное состояние в официальную сборку, и мы сообщим вам позже.
Обобщение: Существуют различные причины получения результатов производительности. Некоторые из них решаются с помощью упомянутого выше бета-патча, некоторые связаны с тем, как вы измеряете и какие действия выполняете. Javonet во многих случаях является самой быстрой встроенной технологией интеграции между .NET и Java , , признанной в тестах многих наших клиентов и пользующейся доверием в таких решениях, как высокочастотная торговля и обработка данных в режиме реального времени. управление производственными и медицинскими приборами и другими ... Конечно, все еще существуют ситуации и случаи, когда производительность варьируется. Достижение самых высоких результатов является одним из наших ключевых приоритетов, следуя одному из наших принципов «будь быстрее с каждым выпуском». Мы всегда принимаем вызовы производительности наших клиентов, внедряя улучшения по требованию, если это необходимо. Мы принимаем ваше и постараемся оптимизировать поиск больших примитивных массивов.
Пожалуйста, протестируйте патч, приведенный выше, который должен значительно улучшить работу, но все же пострадает от экологических факторов: 4 и 5.
Обновление 2018-04-30: Мы начали реализацию модернизированного модуля оптимизации для решения таких сценариев, как ваш, с сохранением максимально возможной производительности, почти равной собственной. По ссылке ниже вы найдете альфа-релиз, который работает в «usePrimitiveArraysMode» для неуниверсальных методов, возвращающих «double []» без аргументов ref / out. То есть double [] CreateArray () или double [] CreateArray (int size) и т. д. *
http://download.javonet.com/1.5/javonet-1.5hf15-primitivearrays-opti-jtdn.jar