Сколько JSR-292 (invokedynamic) будет влиять на производительность Groovy? - PullRequest
9 голосов
/ 06 января 2010

Существует ли оценка, которая говорит о том, насколько JSR-292 повлияет на производительность Groovy?

Ответы [ 4 ]

4 голосов
/ 16 января 2013

invokedynamic - действительно сложная история, поскольку характеристики производительности все время меняются в JDK7. Во время портирования Groovy на indy я очень, очень близко подошел к Java, примерно в 1.5 раза. Но я должен использовать catchExceptionGuard, который снижает производительность до уровня 3-4. Нам все еще нужно исследовать способы избежать использования этой охраны. Возможно, нам придется сломать некоторый существующий код в Groovy 2.2 для этого. Во всяком случае, мне не нужна защита для отката invokeMethod, как упоминалось выше. Именно для GroovyRuntimeExceptions, возможно, содержащих другие исключения, я должен развернуть или сделать другие вещи. Таким образом, теоретически возможная производительность, по-видимому, находится между Java и половиной скорости Java для существующих методов. Выполнение вызовов invokeMethod - это совсем другая история.

Если вам нужно больше, используйте @CompileStatic в Groovy 2.0.

3 голосов
/ 06 января 2010

Я не думаю, что эталон пока есть, и пока кто-то не выполнит его, мы можем только догадываться ...

Вы можете найти этот пост в этом вопросе интересным.

2 голосов
/ 06 января 2010

В целом это будет примерно в 10-50 раз быстрее.

http://www.mail-archive.com/mlvm-dev@openjdk.java.net/msg00819.html

0 голосов
/ 30 апреля 2011

Я не уверен, насколько это применимо к Groovy. Если я хорошо помню, у Groovy есть некоторые запасные варианты (например, метод invokeMethod). Я думаю, что невозможно просто использовать запасной вариант с invokedynamic.

Однако есть несколько способов:

  • Поймать исключение, которое выдается, когда метод не найден. К сожалению, вероятно, необходимо проанализировать трассировку стека, потому что вы не можете быть уверены, откуда она выбрасывается. Это может быть значительным замедлением при вызове несуществующего метода, независимо от того, обрабатывается ли он обратным вызовом invokeMethod.
  • Посмотрите на Groovy ++. Это позволяет вам использовать статическую типизацию, если вы удовлетворяете некоторым ограничениям. В таком случае может быть возможно разрешить вам переключиться в «строгий динамический режим», который не допускает этих откатов.
...