Странное поведение с переносимыми перьями, вложенными в портлет JSF [дубликат]

С JSF 2.0 вы можете присоединить слушателя к системному событию

<h:outputText value="#{ManagedBean.someProperty}">
   <f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />
</h:outputText>

. В качестве альтернативы вы можете заключить страницу JSF в тег f:view

<f:view>
   <f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />

      .. jsf page here...

<f:view>

Первоначально опубликовано в форуме PrimeFaces @ http://forum.primefaces.org/viewtopic.php?f=3&t=29546

Недавно я был одержим оценивая производительность моего приложения, настраивая запросы JPA, заменяя динамические SQL-запросы именованными запросами, и только сегодня утром я узнал, что метод getter больше похож на HOT SPOT в Java Visual VM, чем остальная часть моего кода (или большинства мой код).

Метод Getter:

PageNavigationController.getGmapsAutoComplete()

Ссылка на ui: include in in index.xhtml

Ниже вы увидите, что PageNavigationController.getGmapsAutoComplete () является HOT SPOT (проблема с производительностью) в Java Visual VM. Если вы посмотрите дальше, на экране захвата, вы увидите, что getLazyModel (), PrimeFaces ленивый метод datatable getter, также является горячей точкой, только когда enduser делает много «ленивых данных» типа вещей / операций / задач в приложении. :]

[/g1]

См. (исходный) код ниже.

public Boolean getGmapsAutoComplete() {
    switch (page) {
        case "/orders/pf_Add.xhtml":
        case "/orders/pf_Edit.xhtml":
        case "/orders/pf_EditDriverVehicles.xhtml":
            gmapsAutoComplete = true;
            break;
        default:
            gmapsAutoComplete = false;
            break;
    }
    return gmapsAutoComplete;
}

Называется в index.xhtml:

<h:head>
    <ui:include src="#{pageNavigationController.gmapsAutoComplete ? '/head_gmapsAutoComplete.xhtml' : (pageNavigationController.gmaps ? '/head_gmaps.xhtml' : '/head_default.xhtml')}"/>
</h:head>

Решение: поскольку это метод «getter», переместите код и присвойте значение gmapsAutoComplete до вызова метода; см. код ниже.

/*
 * 2013-04-06 moved switch {...} to updateGmapsAutoComplete()
 *            because performance = 115ms (hot spot) while
 *            navigating through web app
 */
public Boolean getGmapsAutoComplete() {
    return gmapsAutoComplete;
}

/*
 * ALWAYS call this method after "page = ..."
 */
private void updateGmapsAutoComplete() {
    switch (page) {
        case "/orders/pf_Add.xhtml":
        case "/orders/pf_Edit.xhtml":
        case "/orders/pf_EditDriverVehicles.xhtml":
            gmapsAutoComplete = true;
            break;
        default:
            gmapsAutoComplete = false;
            break;
    }
}

Результаты теста: PageNavigationController.getGmapsAutoComplete () больше не является HOT SPOT в Java Visual VM (больше не отображается)

тема, так как многие из опытных пользователей посоветовали младшим разработчикам JSF НЕ добавлять код в методы «getter». :)

Вероятно, вы можете использовать AOP для создания своего рода Aspect, который кэшировал результаты наших геттеров для настраиваемого количества времени. Это может помешать вам копировать и вставлять код шаблона в десятки аксессуаров.

Если значение someProperty дорого рассчитать, это потенциально может быть проблемой.

Это то, что мы называем преждевременной оптимизацией. В редком случае, когда профилировщик говорит вам, что вычисление свойства настолько необычайно дорого, что его трижды, а не один раз оказывает значительное влияние на производительность, вы добавляете кеширование, как вы описываете. Но если вы не делаете что-то действительно глупое, как факторинговые простые числа или получаете доступ к базе данных в геттере, ваш код, скорее всего, имеет десяток худших недостатков в тех местах, о которых вы никогда не думали.