[Bug 69659] Automatic JSP EL optimization
https://bz.apache.org/bugzilla/show_bug.cgi?id=69659 --- Comment #2 from John Engebretson --- Thanks Christopher! Very helpful. > How much mileage could you get out of a simple regex-style replacement that > looks for very specific things like this? I would get excellent mileage, although I'm not certain whether I'd go after the String or the parsed AstNodes. TBD. > It would be best to perform these optimizations during compilation of the > statement. Agreed, and easily done. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69659] Automatic JSP EL optimization
https://bz.apache.org/bugzilla/show_bug.cgi?id=69659 --- Comment #1 from Christopher Schultz --- An optimizing compiler won't add much because it can't really prove those things are true unless we teach it, which is probably not worth it. Even the JIT probably isn't able to figure out that it's duplicated effort because the logic is so "far apart" (separated by && but radically different execution paths). It would be best to perform these optimizations during compilation of the statement. I don't know enough about JSP compilation and EL evaluation to know when that kind of thing could happen, but conceptually, looking at the AST of the expression should allow you to perform some optimizations by replacing the complex expression with a simpler one. Specifically, look for things like this: not empty X && statement-involving-X The LHS is easy, but the RHS is not so easy, since it could be arbitrarily complex. Can we convince ourselves that: not empty X && *anything* can simply be replaced with: *anything* ? I think the answer is no, since "not empty X" might be the only time X is referenced: removing it would change the behavior, obviously. I'm not sure there really is a general solution for this kind of thing. Honestly, education your engineers doesn't sound like a high bar: I would do that. Modifying your entire code-base is of course another matter. How much mileage could you get out of a simple regex-style replacement that looks for very specific things like this? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[PR] Adding nonstandard catch, if, choose/when/otherwise [tomcat]
jengebr opened a new pull request, #845: URL: https://github.com/apache/tomcat/pull/845 Adds non-standard implementations of `c:catch`, `c:if`, `c:choose`, `c:when`, and `c:otherwise`. Note that incorrectly structured choose/when/otherwise combinations are blocked by the tag lib validation, so an entire class of edge cases does not need to be supported or tested. Along the way I cleaned up the code into implementations of a new interface `NonstandardCustomTagGenerator`. Application owners cannot yet create their own overrides (exposing fields is problematic) but this organizes the now-seven tag implementations and is a step in the right direction to open it up. When activated, these changes eliminate the vast majority of tags on my application's JSPs, with impressive performance results. I have no immediate plans to support other tags. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
