You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kevin Burton <bu...@rojo.com> on 2005/05/29 21:41:41 UTC
Tomcat optimization... saving internal strings with character encoding
at compile time.
Another area that I'm noticing that Tomcat is spending a LOT of time in
is with character encoding. Its not a ton of time but its really
showing up as one of the top 20 areas of our webapp.
Internally its either storing text as a java.lang.String or with
genStrAsCharArray ... a char array
Most people are probably using a fixed character encoding. For example
we use UTF8. I doubt they're changing charset on the fly.
Its a waste of CPU to continually encode these strings. This isn't just
theoretical as I'm seeing our webapp do this internally via JProfiler.
Why not have strings fixed to a character coding at runtime? While this
would yield inflexibility it would increase performance.
This could be a new feature called genStrAsEncodedByteArray... which
would just store the string as a byte[] and output it directly.
The only thing that would need to be encoded in this setup would be
dynamic strings from EL.
It would also save more memory for English text since strings no longer
are stored in 32bit but just UTF8 encoded 8 bit values.
It would slow down compile time though because Jasper would now need to
call toByteArray() on all your strings.
Thoughts?
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Tomcat optimization... saving internal strings with character encoding at compile time.
Posted by Remy Maucherat <re...@gmail.com>.
On 5/29/05, Kevin Burton <bu...@rojo.com> wrote:
>
> Another area that I'm noticing that Tomcat is spending a LOT of time in
> is with character encoding. Its not a ton of time but its really
> showing up as one of the top 20 areas of our webapp.
>
> Internally its either storing text as a java.lang.String or with
> genStrAsCharArray ... a char array
>
> Most people are probably using a fixed character encoding. For example
> we use UTF8. I doubt they're changing charset on the fly.
>
> Its a waste of CPU to continually encode these strings. This isn't just
> theoretical as I'm seeing our webapp do this internally via JProfiler.
>
> Why not have strings fixed to a character coding at runtime? While this
> would yield inflexibility it would increase performance.
>
> This could be a new feature called genStrAsEncodedByteArray... which
> would just store the string as a byte[] and output it directly.
>
> The only thing that would need to be encoded in this setup would be
> dynamic strings from EL.
>
> It would also save more memory for English text since strings no longer
> are stored in 32bit but just UTF8 encoded 8 bit values.
>
> It would slow down compile time though because Jasper would now need to
> call toByteArray() on all your strings.
>
> Thoughts?
This is obvious.
This is not an implementable optimization idea, as you cannot use both
a writer and an out stream in a servlet. If this was doable, then
obviously constant strings would be cached as byte arrays.
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org