Re: [OS-webwork] (somewhat OT) velocity vs jsp
Alright, so based on the feedback so far, the consensus seems to be: webwork jsp UI tags are much slower than velocity equivalents. So the culprit seems to be the webwork UI tags, not jsp itself. On Thursday, March 13, 2003, at 12:13 PM, boxed wrote: scriptlets will probably be almost as fast, I'm guessing. Tags could be much slower, since the way that containers handle tags is different for each container. As I've understood it the tag overhead itself isn't really that big of an issue, the tags ARE reused after all. The JSP include the webwork UI tags use, however, is HORRIBLY slow. Velocity includes are practically no time whatsoever. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] (somewhat OT) velocity vs jsp
Hani, It is fairly simple to test - given that CVS HEAD has tags based on either velocity or jsp. There are two sources of potential slowness with jsp: - parsing rendering overhead - rd.include() overhead. From my experience both of the above can be reduced by using velocity. Tomcat (until recently) was very slow doing an rd.include(), which is the way that the webwork tags work (including the template). However, the currently commited velocity tags (1.3/CVS HEAD) still use the rd.include(), and the velocity servlet to serve the content. They still serve the page much faster than JSP (on almost all containers), so there must some overhead in the parsing rendering also. Overall, JSP compilation and servlet containers are improving, and one day Tomcat Jetty will be much closer to Orion/Resin. However, if you are looking for a constant (fast) time across containers, then you choose velocity, as it is a known variable. That given, there are a lot of things about velocity that shit me, such as #foreach(Map) iterating across the keyset and not the entryset, and few ugly parsing issue that make it hard to do webwork's funky loosely-typed syntax easily. Cheers, Scott Hani Suleiman wrote: Alright, so based on the feedback so far, the consensus seems to be: webwork jsp UI tags are much slower than velocity equivalents. So the culprit seems to be the webwork UI tags, not jsp itself. On Thursday, March 13, 2003, at 12:13 PM, boxed wrote: scriptlets will probably be almost as fast, I'm guessing. Tags could be much slower, since the way that containers handle tags is different for each container. As I've understood it the tag overhead itself isn't really that big of an issue, the tags ARE reused after all. The JSP include the webwork UI tags use, however, is HORRIBLY slow. Velocity includes are practically no time whatsoever. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support --- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] (somewhat OT) velocity vs jsp
Hani Suleiman wrote: Alright, so based on the feedback so far, the consensus seems to be: webwork jsp UI tags are much slower than velocity equivalents. So the culprit seems to be the webwork UI tags, not jsp itself. Well, it's the base JSP include overhead that is bad, really. Including a JSP has in my own benchmarks a 2ms overhead. For some applications, like our portal product as an example, that is just totally unacceptable. Velocity has a vastly lower overhead for includes, as boxed said practically no time at all. /Rickard --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] (somewhat OT) velocity vs jsp
Well, again, that tests webwork, not jsp vs velocity. A 'real' test would be one where webwork is NOT part of the equation, or at least, there is a VERY thin 'glue' UI specific layer. Also using tomcat for any kind of performance test like this one would be rather...silly. It'd be like using jboss to prove that ejbs suck. Of COURSE a given tech will suck if you choose a braindead impl. In the case of velocity vs jsp, I'd be inclined to discard any tests on servers other than orion/resin. For one thing, I'm pretty sure that the developers of those containers would very quickly scramble to speed up their jsp impls if a good example can prove that it's slower than using velocity. On Thursday, March 13, 2003, at 12:50 PM, Scott Farquhar wrote: Hani, It is fairly simple to test - given that CVS HEAD has tags based on either velocity or jsp. There are two sources of potential slowness with jsp: - parsing rendering overhead - rd.include() overhead. From my experience both of the above can be reduced by using velocity. Tomcat (until recently) was very slow doing an rd.include(), which is the way that the webwork tags work (including the template). However, the currently commited velocity tags (1.3/CVS HEAD) still use the rd.include(), and the velocity servlet to serve the content. They still serve the page much faster than JSP (on almost all containers), so there must some overhead in the parsing rendering also. Overall, JSP compilation and servlet containers are improving, and one day Tomcat Jetty will be much closer to Orion/Resin. However, if you are looking for a constant (fast) time across containers, then you choose velocity, as it is a known variable. That given, there are a lot of things about velocity that shit me, such as #foreach(Map) iterating across the keyset and not the entryset, and few ugly parsing issue that make it hard to do webwork's funky loosely-typed syntax easily. Cheers, Scott Hani Suleiman wrote: Alright, so based on the feedback so far, the consensus seems to be: webwork jsp UI tags are much slower than velocity equivalents. So the culprit seems to be the webwork UI tags, not jsp itself. On Thursday, March 13, 2003, at 12:13 PM, boxed wrote: scriptlets will probably be almost as fast, I'm guessing. Tags could be much slower, since the way that containers handle tags is different for each container. As I've understood it the tag overhead itself isn't really that big of an issue, the tags ARE reused after all. The JSP include the webwork UI tags use, however, is HORRIBLY slow. Velocity includes are practically no time whatsoever. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support --- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] (somewhat OT) velocity vs jsp
Hani Suleiman wrote: Most people seem to be in agreement that velocity templates are at least an order of magnitude faster that jsp pages, which to me seems a bit...odd. So I was wondering if anyone has good (small) examples of this being the case. Webwork examples don't count as good examples because they involve a lot more than just jsp vs velocity, and might well be due to differences in webwork's velocity stuff vs webwork's jsp taglib. So, can anyone take up the challenge, and prove to me that a velocity page that prints out some bean properties is faster than a jsp page which does the exact same thing? Maybe a very basic sample app that anyone can run to see for themselves? Well, we have built our entire portal product on WebWork/Velocity, and although I don't have the same in JSP I'm rather convinced that the performance we get is to a large extent due to our use of Velocity. Here's a sample page: http://www.konj.se/index.html This page assembles a whole lot of dynamic data (ALL data you see is taken from an object model) and uses Velocity to render it. Typically such pages render below 100ms, and as you can see it's a whole lot more complex than the MonthList.jsp page which takes forever to render in JSP. Not sure if this helps you, but I can tell you that at least I am very happy with the decision we made to use Velocity. regards, Rickard --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] (somewhat OT) velocity vs jsp
Well, I think there are two cases of JSP you need to evaluate: -JSP with pure scriptlets -JSP with JSP tags scriptlets will probably be almost as fast, I'm guessing. Tags could be much slower, since the way that containers handle tags is different for each container. The main thing to remember is that with velocity, printing out the foo bean property is just $foo, which is almost a direct map to vs.find(foo). But in JSP you have to do ww:property value=foo/ which requires the container to handle the tag properly, then execute the tag code, and then finally make the vs.find(foo) call. I think it's that extra work that must be done (when using JSP tags in WW) that causes such a large overhead. These are just thoughts at 11:46PM, please take them with a grain of salt :) -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 7:41 PM Subject: [OS-webwork] (somewhat OT) velocity vs jsp Most people seem to be in agreement that velocity templates are at least an order of magnitude faster that jsp pages, which to me seems a bit...odd. So I was wondering if anyone has good (small) examples of this being the case. Webwork examples don't count as good examples because they involve a lot more than just jsp vs velocity, and might well be due to differences in webwork's velocity stuff vs webwork's jsp taglib. So, can anyone take up the challenge, and prove to me that a velocity page that prints out some bean properties is faster than a jsp page which does the exact same thing? Maybe a very basic sample app that anyone can run to see for themselves? Hani --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
