You have to be and are comparing apples and oranges, Kevin, because
JSP *is* Java. DOH! It cannot run slower than what it is. You
probably are comparing just running a Java method like setFoo(String
foo) { this.foo = foo; } where the parameter foo has the value bar.
But, this is really
Just to check are your precompiling the jsp page?
On 5/28/05, Kevin Burton [EMAIL PROTECTED] wrote:
I've been tuning our application trying to get the maximum performance
out if the system as possible.
I've been throwing the system at jprofiler and allowing it to tell me
where to
Whether he is precompiling or not, Peng, and I know that is important,
he is still comparing applies and oranges. Further, he is comparing
the setup for any and all uses of c:set with pojo code that he does
not give the same infrastructure accounting, apparently. The whole
question fails to see
On 5/28/05, Kevin Burton [EMAIL PROTECTED] wrote:
I've been tuning our application trying to get the maximum performance
out if the system as possible.
I've been throwing the system at jprofiler and allowing it to tell me
where to optimized.
In short Tomcat is slower than our DB,
I would advise using the tag plugins to change tags to pure java. JSP
tags are considerably slower than pure JSP + java, but many people
find that combination bad on maintenance. When remy and I worked on
the book back in 2002, I did quite a bit of comparison between pure
java and JSTL.
as you
On 5/28/05, Peter Lin [EMAIL PROTECTED] wrote:
as you see already, using JSTL means a single line of code gets
converted to several lines of JSTL api calls. once you look at how
many classes are involved in executing JSTL, it's pretty clear it's
using much more memory and causing more GC. The
correction to my previous email.
On 5/28/05, Remy Maucherat [EMAIL PROTECTED] wrote:
On 5/28/05, Peter Lin [EMAIL PROTECTED] wrote:
as you see already, using JSTL means a single line of code gets
converted to several lines of JSTL api calls. once you look at how
many classes are involved
I agree with this. There really is *not* a lot of code in what Kevin
showed us, because the page code has to be there whether you have one
or 500 invocations, tags, on the page. This just makes it look large
because all the setup is attributed to one measely little tag.
On 5/28/05, Remy
Dakota Jack wrote:
You have to be and are comparing apples and oranges, Kevin,
Perhaps... but my point was that JSP 2.0 doesn't HAVE to be this slow! :)
because
JSP *is* Java. DOH! It cannot run slower than what it is.
No.. it could run slower... I'm sure the Tomcat developers will
Peng Tuck Kwok wrote:
Just to check are your precompiling the jsp page?
Yes... we're precompiling them before we deploy. I'd recommend most
people do that if they have the time.
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want
Remy Maucherat wrote:
For production configuration for Jasper, see:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration
Cool... we have those set but I didn't see *genStrAsCharArray
*
**The interesting thing is that jprofiler clearly shows a big
Peter Lin wrote:
Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to
measure the actual cost of from a performance perspective. The
performance difference isn't noticeable if a page has less than 50
tags. With 200+ tags, the performance difference does range from 2-5x
slower
Remy Maucherat wrote:
It will obviously use more CPU and make more API calls. However, it
does not allocate any objects, but instead will reuse per page objects
(which is very fast). So overall, it sounds weird to me that the
bottleneck would be on tag invocation.
In the end, it's hard to beat
Remy Maucherat wrote:
For production configuration for Jasper, see:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration
Do you know offhand if genStrAsCharArray has to be passed to jspc? I
didn't notice this as one of the command line options in
On 5/28/05, Kevin Burton [EMAIL PROTECTED] wrote:
Remy Maucherat wrote:
It will obviously use more CPU and make more API calls. However, it
does not allocate any objects, but instead will reuse per page objects
(which is very fast). So overall, it sounds weird to me that the
bottleneck
I've been tuning our application trying to get the maximum performance
out if the system as possible.
I've been throwing the system at jprofiler and allowing it to tell me
where to optimized.
In short Tomcat is slower than our DB, filesystem,. network and all
other systems by about 4x.
16 matches
Mail list logo
