Py4J имеет большие накладные расходы, чем Jython и JPype

Question

После поиска возможности запуска Java-кода из приложения Django (python), я узнал, что Py4J - лучший вариант для меня. Я попробовал подпроцесс Jython, JPype и Python, и каждый из них имеет определенные ограничения:

• Jython. Мое приложение работает на питоне.
• JPype багги. Вы можете запустить JVM только один раз, после чего он не сможет начать работу снова.
• Подпроцесс Python. Не удается передать объект Java между Python и Java из-за обычного консольного вызова.

На сайте Py4J написано:

С точки зрения производительности, Py4J имеет большую нагрузку, чем оба предыдущих решений (Jython и JPype), потому что он опирается на патрубках, но если производительность Неприкосновенный для вашего приложения доступ к объектам Java из программ Python может быть не лучшей идеей.

В моем приложении производительность критическая, потому что я работаю с Машинным учебным каркасом Mahout. Мой вопрос: будет ли Махут работать медленнее из-за сервера шлюза Py4J, или это накладные расходы означают, что вызывать методы Java из функций Python медленнее (в последнем случае производительность Mahout не будет проблемой, и я могу использовать Py4J).

Answer 1

Я не знаю Mahout. Но подумайте об этом: по крайней мере, с JPype и Py4J вы столкнетесь с производительностью при преобразовании типов из Java в Python и наоборот. Попробуйте минимизировать вызовы между языками. Возможно, это альтернатива для вас, чтобы закодировать тонкую оболочку на Java, которая объединяет многие Javacalls с одним вызовом python2java.

Answer 2

PySpark использует Py4J довольно успешно. Если все тяжелые действия выполняются на Spark (или Mahout в вашем случае), и вы просто хотите вернуть результат обратно в «драйвер»/код Python, тогда Py4J может работать для вас очень хорошо.

Answer 3

Поскольку производительность также связана с вашим использованием screnario (как часто вы вызываете скрипт и насколько велики перемещаемые данные), а также потому, что разные решения имеют свои особые преимущества/недостатки, я создал API для переключения между различными реализациями без необходимости изменять ваш скрипт python: https://github.com/subes/invesdwin-context-python

Таким образом, тестирование того, что работает лучше всего или просто гибкость в отношении того, что нужно развернуть, очень просто.