Groovy: низкая производительность многопоточности и медленные вычисления по сравнению с Java?

Question

Согласно статье Groovy имеет

К сожалению, в то же время Groovy очень медленно работает во время выполнения.Как человек, который много сделал для улучшения производительности Groovy, я могу говорить об этом очень открыто.Groovy очень медленно.Вы можете легко ожидать, что некоторые вычисления Groovy или преобразование данных, переписанные на Java, станут в 3-5 раз быстрее.Обычно этот коэффициент составляет 8-12, а иногда даже выше.Кто-то может сказать, что Java всегда к вашим услугам, и никто не использует Groovy для вычислений или обработки данных ... Но, эй, это именно моя точка зрения - почему мы должны ограничивать себя только сценариями или обработкой простых веб-страниц?

Что еще хуже, тот факт, что Groovy плохо масштабируется для многоядерных компьютеров, означает, что несколько потоков, выполняющих код, скомпилированный Groovy, действительно мешают друг другу работать быстро.Для многих приложений это не проблема, но для многих других это просто show-stopper.

Может ли кто-нибудь доказать или опровергнуть эти абзацы?

Меня особенно беспокоит производительность многопоточности.

Answer 1

В настоящее время предпринимаются усилия по улучшению скорости Groovy, но следует сказать, что 9 раз в 10 производительность не является проблемой.

Однако, где это проблема, вы можете либо напишите этот код на Java (и легко интегрируйте этот класс Java в ваш код на Groovy), или, если вы хотите оставаться полностью нестандартным, вы можете использовать Groovy ++ , который повышает скоростьGroovy, сделав его более статически типизированным (с некоторыми тяжелыми типами, чтобы избавить вас от необходимости делать все самостоятельно, как с Java)

Groovy 1.8b4 (в настоящее время в бета-версии), также поставляется с GPars framework в комплекте с ним.

Проект GPars предлагает разработчикам новые интуитивно понятные и безопасные способы одновременной, асинхронной и распределенной обработки задач Java или Groovy с использованием возможностей платформы Java.и гибкость языка Groovy.

{edit июль 2012}

Groovy 2.0 имеет аннотацию CompileStaticкоторый вы, возможно, захотите изучить (так как сейчас Groovy ++ не разрабатывался уже несколько месяцев). Этот вопрос здесь имеет несколько чисел ...

Answer 2

Обычно этот коэффициент составляет 8-12, а иногда даже выше.Кто-то может сказать, что Java всегда к вашим услугам, и никто не использует Groovy для вычислений или обработки данных ... Но, эй, это именно моя точка зрения - почему мы должны ограничивать себя только сценариями или обработкой простых веб-страниц?

Нам больше не нужно ограничивать себя!Groovy 1.8 вышел!; -)

" Groovy 1.8.x прототип для fib (42) занимает около 3,8 с ( только на 12% медленнее, чем Java, в сто раз быстрее, чемGroovy 1.0 ) Поэтому мы больше не можем поощрять людей писать такие «горячие точки» на Java. "

Источник: http://www.wiki.jvmlangsummit.com/images/0/04/Theodorou-Faster-Groovy-1.8.pdf

Теперь это Groovy vs. Scalaв исполнении!Пожалуйста, проверьте это:

"Я впечатлен тем, насколько производительность Groovy улучшилась для численных вычислений. Groovy 1,8 в моем проекте jlab (http://code.google.com/p/jlabgroovy/) иногдапревосходит производительность Scala в моем другом проекте ScalaLab (http://code.google.com/p/scalalab) !! "

Источник: http://groovy.329449.n5.nabble.com/Great-improvements-in-Groovy-s-performance-for-numerical-computing-td4334768.html

Для параллельной обработки вы можете использовать уже встроенные GPars!

Ура

Answer 3

Я могу лишь предоставить отдельные примеры плохой производительности Groovy в вычислениях (которым, по общему признанию, около 2 лет):

Я реализовал алгоритм оптимизации в Groovy и нашел его невыносимо медленным.Профилирование показало, что он провел около 60% своего времени в BigDecimal.divide().Виновником оказалась одна строка с очень простым арифметическим вычислением значений с плавающей запятой, которые Groovy почему-то настаивал на преобразовании в BigDecimal.Я попытался избежать этого, но потерпел неудачу, поэтому переписал эту часть приложения на Java и увидел, что время выполнения сократилось на 90%.

Answer 4

"Прототип Groovy 1.8.x для fib (42) занимает около 3,8 с (всего на 12% медленнее, чем Java, более чем в сто раз быстрее, чем Groovy 1.0). Поэтому мы больше не можем поощрять людей писать такие« горячие точки »вJava. "

Я только что попробовал, и это очень неточно.Groovy 1.8 для fib (42) в ~ 25 раз медленнее java.В моем тесте java fib (42) занимает 2 секунды, в то время как 1.8 и 1.7.8 занимают около 52 секунд.

Groovy все еще медленный ....