[09:52:07 CST(-0600)] <EricDalquist> looks like we might be getting some more QA resources for uP4 
[10:16:01 CST(-0600)] <EricDalquist> athena: you there?
[10:26:17 CST(-0600)] <Arvids> EricDalquist, glad you´re here
[10:26:24 CST(-0600)] <EricDalquist> yeah, was out sick yesterday
[10:27:15 CST(-0600)] <Arvids> I rewrote that tab ID lookup - XPath did lookups in 1-50ms, but manual traversing does the same thing in 0.05-0.15ms
[10:27:37 CST(-0600)] <EricDalquist> wow nice
[10:27:44 CST(-0600)] <EricDalquist> +1 for that change
[10:27:45 CST(-0600)] <Arvids> that speeds up response times by 30-40%
[10:28:08 CST(-0600)] * EricDalquist cannot wait to have time to just re-write the layout manager/store layer
[10:28:25 CST(-0600)] <EricDalquist> xslt is find for the rendering pipeline but it would be nice to not treat the actual layouts as DOMs
[10:28:26 CST(-0600)] <Arvids> it turns out that those lookups are made at each URL building request
[10:28:38 CST(-0600)] <EricDalquist> ah ... yeah they would be
[10:28:56 CST(-0600)] <EricDalquist> one thing I've always wanted to write but never had time would be a @RequestCache annotation
[10:29:00 CST(-0600)] <EricDalquist> and supporting code
[10:29:07 CST(-0600)] <Arvids> btw, i can give you a patch, but I won´t have time to commit it today myself
[10:29:14 CST(-0600)] <EricDalquist> that will work
[10:29:28 CST(-0600)] <EricDalquist> being able to annotated a method with @RequestCache and have the method result be cached in a request attribute
[10:30:44 CST(-0600)] <Arvids> https://gist.github.com/1607350
[10:31:42 CST(-0600)] <EricDalquist> so have you tested this on mobile?
[10:31:54 CST(-0600)] <Arvids> no
[10:32:10 CST(-0600)] <EricDalquist> the way things work the UrlNodeSyntaxHelper impl is associated with the structure transform
[10:32:18 CST(-0600)] <EricDalquist> so the logic to find the correct tab needs to be in there
[10:32:57 CST(-0600)] <EricDalquist> since a different structure, like mobile, doesn't have the same url structure as the tab/column structure
[10:34:16 CST(-0600)] <Arvids> ok, i hope i will have some time to inspect that next week
[10:34:31 CST(-0600)] <EricDalquist> well at least we know that it is a problem
[10:35:03 CST(-0600)] <Arvids> yeah, i also did some search on google.. and it gave very little results, but there were some hints
[10:35:12 CST(-0600)] <Arvids> one is: https://issues.apache.org/jira/browse/XALANJ-2540
[10:36:13 CST(-0600)] <Arvids> http://stackoverflow.com/questions/6340802/java-xpath-apache-jaxp-implementation-performance
[10:36:43 CST(-0600)] <Arvids> the one question from stackoverflow is supporting my conclusions - XPath is slow
[10:36:47 CST(-0600)] <EricDalquist> uhg
[10:36:49 CST(-0600)] <EricDalquist> that sucks
[10:37:01 CST(-0600)] <Arvids> yes, it does
[10:37:39 CST(-0600)] <Arvids> it is very nice to write some delarative code that looks up the stuff you want... but the performance penalty is too great
[10:37:50 CST(-0600)] <Arvids> declarative*
[10:37:54 CST(-0600)] <EricDalquist> yeah
[10:38:06 CST(-0600)] <EricDalquist> the sad thing is it shouldn't be that expensive
[10:38:17 CST(-0600)] <EricDalquist> and there are alternative xpath impls for java that I'm betting are fast
[10:38:30 CST(-0600)] <EricDalquist> but last I looked jdom and dom4j are both essentially dead