Зависит от задачи, если требуется несколько раз создать и много больше раз выполнить — тогда всё окей. Если много раз создать и по одному разу вычислить — не очень.
Ничего вы не поняли, учить ничего не надо. Мораль была такая: javassist компилирует в runtime не хуже javac, и результаты доказывали это.
И чтобы расставить все точки над i — результат с замером скорости генерации. На среднее время генерации очень сильно повлиял первый запуск, когда погружались все классы. Было 108 мс у javassist и 27 мс у script engine (кстати это мало что говорит, могут отметить профессионалы microbenchmark'инга). Но дальше видно, что разницы принципиальной нет.
Если интересно, я добавил третьим методом вычисление с помощью js. ужас — мягко сказано. в тесте я складываю результат выполнения функции в цикле. на тестах из статьи — приблизительно 350 мс на 100 миллионов вызовов. Для того чтобы дождаться выполнение теста с js — пришлось уменьшить число прогонов в 1000 раз.
Вышло 4с на 100 тысяч раз. Итого в 11 тысяч раз медленнее, если я правильно посчитал. Вот уж производительность должна быть действительно неважна
Мне всегда была интересна такая вещь — на билетиках пишется, что система патентована шведской компанией Q-Matic. Получается, что я не смогу реализовать такую систему собственными силами?
Спасибо, по настоящему полезный комментарий. Есть несколько хороших моментов в этой методике. Главный — cglib действительно быстрее reflection, а значит я не зря переводит всё это :)
Oracle ещё с мезозойской эры принимает участие в развитии java. И то как Oracle завязан на Java известно любому, хоть раз установившему оракловскую базу.
«два раза одну версии одной библиотеки в общем случае качать не придётся» — сколько проектов у вас не было б. копии сохраняются в win — «C:\Documents and Settings\user\.m2\»
Именно так. Библиотеки скачиваются из публичных репозиторев. Однако mvn аккуратно и очень педантично сохраняет всё скаченное локально. Поэтому можно относительно не бояться — два раза одну версии одной библиотеки в общем случае качать не придётся.
Сами зависимости объявляются в xml-файле, а файл находится под контролем версий. Поэтому если вы использовали допустим версию 1.3, а вдруг решили обновиться — вы просто правите цифру в xml-файле — 1.4. Теперь билд будет использовать новую версию.
Глупость
Храним библиотеки, в том числе открытые, в SVN Следствие
Сложная процедура обновления конкретной библиотеки, особенно если она имеет зависимости. Большой трафик к серверу Что я должен был сделать
Использовать maven
Глупость
Использовали собственные реализации очередей и семафоров Следствие
Потраченное время, сложный код, ошибки собственных реализаций Что я должен был сделать
Убедить в необходимости миграции на Java 5, использовать соответствующие классы из Collection API и java.util.concurrency
Раз уж в этом треде обсуждали groovy — может состряпаете пример? Ибо я не в зуб ногой.
И чтобы расставить все точки над i — результат с замером скорости генерации. На среднее время генерации очень сильно повлиял первый запуск, когда погружались все классы. Было 108 мс у javassist и 27 мс у script engine (кстати это мало что говорит, могут отметить профессионалы microbenchmark'инга). Но дальше видно, что разницы принципиальной нет.
tatistics: total| amount| last| last 5| last 10| avg| dev| operation 111.00| 20.00| 0.00| 0.00| 0.00| 5.55| 5.53| .. runtime initialization 0.00| 20.00| 0.00| 0.00| 0.00| 0.00| 0.00| .. compile time initialization 100.00| 20.00| 4.00| 3.00| 3.00| 5.00| 1.20| .. script initialization 1883.00| 20.00| 84.00| 85.00| 90.00| 94.15| 4.58| .. runtime calc x 10000000 1682.00| 20.00| 91.00| 88.00| 88.00| 84.10| 1.91| .. compile-time calc x 10000000 9750.00| 20.00| 433.00| 416.00| 420.00| 487.50| 59.32| .. script calc x 10000Вышло 4с на 100 тысяч раз. Итого в 11 тысяч раз медленнее, если я правильно посчитал. Вот уж производительность должна быть действительно неважна
Statistics: total| amount| last| last 5| last 10| avg| dev| operation 4.00| 8.00| 0.00| 0.00| 0.00| 0.50| 0.29| .. runtime calc 2.00| 8.00| 1.00| 0.00| 0.00| 0.25| 0.17| .. compile-time calc 30504.00| 8.00| 3913.00| 3698.00| 3050.00| 3813.00| 182.28| .. script calcPreparing for reflective method access: 2683
Reflective method access: 22028
Preparing for reflective accessible method access: 1746
Reflective accessible method access: 725
Preparing for fast reflective method access: 3530
Fast reflective method access: 1692
Preparing for fast reflective method access (2): 10953
Fast reflective method access (2): 588
название топика отталкивает, а ведь внутри дельный скрипт
Сами зависимости объявляются в xml-файле, а файл находится под контролем версий. Поэтому если вы использовали допустим версию 1.3, а вдруг решили обновиться — вы просто правите цифру в xml-файле — 1.4. Теперь билд будет использовать новую версию.
Храним библиотеки, в том числе открытые, в SVN
Следствие
Сложная процедура обновления конкретной библиотеки, особенно если она имеет зависимости. Большой трафик к серверу
Что я должен был сделать
Использовать maven
Глупость
Использовали собственные реализации очередей и семафоров
Следствие
Потраченное время, сложный код, ошибки собственных реализаций
Что я должен был сделать
Убедить в необходимости миграции на Java 5, использовать соответствующие классы из Collection API и java.util.concurrency