The profiler shows that for a (large) page, 40% of the effort (20 seconds per such particular page) goes into just parsing the tags and does not seem to process any logic.
So, some streamlining might be in order there, even after this particular issue. Jira issue created with attached profiler screenshot: https://issues.apache.org/jira/browse/WICKET-1910 ** Martin 2008/11/1 Matej Knopp <[EMAIL PROTECTED]>: > Sure this is valid but i can't imagine why this would be a bottleneck. > Unless the webserver does something very weird while retrieving the > header. > > -Matej > > On Sat, Nov 1, 2008 at 6:01 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> looks good, please create a jira issue. >> >> -igor >> >> On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi >> <[EMAIL PROTECTED]> wrote: >>> Hi! >>> >>> I was profiling my Wicket application and noticed that Jetty's >>> getHeader method was hit quite often. >>> >>> It turns out the ServletWebRequest.isAjax method is hit quite often by >>> each of the page elements (I am generating a large HTML report page). >>> Since the Servlet container may not have optimal design for processing >>> the getHeader method, I wonder if the ServletWebRequest.isAjax -method >>> could/should be cached within wicket. >>> >>> I made the following modification to the ServletWebRequest.isAjax >>> method, and measured a notable increase in performance: >>> >>> public boolean isAjax() { >>> if (ajax == null) { >>> ajax = false; >>> >>> String ajaxHeader = httpServletRequest.getHeader("Wicket-Ajax"); >>> if (Strings.isEmpty(ajaxHeader) == false) >>> { >>> try >>> { >>> ajax = Strings.isTrue(ajaxHeader); >>> } >>> catch (StringValueConversionException e) >>> { >>> // We are not interested in this exception but we log it anyway >>> log.debug("Couldn't convert the Wicket-Ajax header: " + >>> ajaxHeader); >>> } >>> } >>> } >>> >>> return ajax; >>> } >>> >>> >>> However, my question remains: is this a valid optimization or does it >>> break the Wicket framework? Should it somehow be incorporated in the >>> next releases? >>> >>> ** >>> Martin >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
