You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2003/01/05 14:32:36 UTC
[5.0] Input optimization
I've committed input optimization similar to the OutputBuffer used in
the Coyote adapter. It appears to work ok (although
BufferedWriter.readLine still needs to be implemented).
I'm against porting this patch to 4.1.x, as it is a risky change (which
will need lots of testing) with only a few cases where it would improve
performance in the real world (InputStream performance is almost
equivalent, and it is used a lot more often than the BufferedReader, as
the integrated FORM POST parsing uses it).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Input optimization
Posted by "Jerome Lacoste (Frisurf)" <la...@frisurf.no>.
On Sun, 2003-01-05 at 18:40, Remy Maucherat wrote:
> Costin Manolache wrote:
> > Great !
>
> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.
I found this:
>>From The Collaborative International Dictionary of English v.0.44
[gcide]:
Disappendent \Dis`ap*pend"ent\, a.
Freed from a former connection or dependence; disconnected.
[R.]
[1913 Webster]
But I don't like it much.
untie() neither. Perhaps changing append() would make it easier to find
an opposite ?
J
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Input optimization
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Costin Manolache wrote:
>>
>>>Great !
>>
>>If you could come up with a better name for the "substract" method ;-)
>>It's supposed to be the opposite of append.
>>
>>The optimization works good. It should help WebDAV as well as web
>>services, as long as they use the Tomcat reader.
>
>
> WebDAV: is there any reason to keep our webdav servlet instead of just
> bundling jakarta-slide ? Can jakarta-slide use the tomcat-specific
> optimizations ( for example using some factory or hook ) ?
Well, there's stuff to do to be able to do that, since Slide is quite
complex (and fairly unoptimized). However, it's modular, so modules
could be written to embed it (and then we could replace the WebDAV
servlet). We'll see how it goes.
I think we could end up packaging it as a module, like other J2EE
related components.
>>Hopefully, I'll be able to write the new mapper soon,
>
>
> My wish list ( if possible ):
>
> - I think the new mapper should be a "global" mapper - i.e. it should
> handle all aspects of the mapping, from vhost and aliases, all contexts
> and up to the servlet wrapper.
> This would allow more optimizations ( a tree or some other tricks ) than
> the current chain of 3-4 hashtable mappers ( one for host, one for ctx,
> one for servlet ).
Yes, I reckon this isn't too efficient. I'll see what I can do.
As for the implementation, a tree would scale better, but a more usual
char based "dumb" solution is far simpler, and may perform well enough.
I think I'll start with that, and see what OptimizeIt says.
More importantly, I'll try to use the mapper for request dispatcher
mapping also, so it can't be too unified (request dispatcher performance
isn't too good right now, and mapping is a big part of the problem).
BTW, I'd like to have other developers understand that all String
operations are really *bad*, not just concatenation, even trim(),
toLowerCase() and other "simpler" operations.
> - Add/remove mapping should be propagated via coyote actions - someday
> jk may intercept the events and inform the native side when a new webapp
> is added.
Yes, I understand.
> - there is an interesting optimization in 3.3 - once a jsp is compiled,
> a prefix mapping is added and the behavior is identical with precompiled
> jsps ( i.e. no jsp servlet or extra overhead - it is a regular servlet ).
> ( the reloading checks are a different story - they can be handled by the
> generated servlet or some other module )
The overhead of the Jasper servlet itself is quite low right now. The
biggest operation is a hashtable lookup, I think.
It's a nice trick, though.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Input optimization
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Great !
>
> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.
>
> The optimization works good. It should help WebDAV as well as web
> services, as long as they use the Tomcat reader.
WebDAV: is there any reason to keep our webdav servlet instead of just
bundling jakarta-slide ? Can jakarta-slide use the tomcat-specific
optimizations ( for example using some factory or hook ) ?
> Hopefully, I'll be able to write the new mapper soon,
My wish list ( if possible ):
- I think the new mapper should be a "global" mapper - i.e. it should
handle all aspects of the mapping, from vhost and aliases, all contexts
and up to the servlet wrapper.
This would allow more optimizations ( a tree or some other tricks ) than
the current chain of 3-4 hashtable mappers ( one for host, one for ctx,
one for servlet ).
- Add/remove mapping should be propagated via coyote actions - someday
jk may intercept the events and inform the native side when a new webapp
is added.
- there is an interesting optimization in 3.3 - once a jsp is compiled,
a prefix mapping is added and the behavior is identical with precompiled
jsps ( i.e. no jsp servlet or extra overhead - it is a regular servlet ).
( the reloading checks are a different story - they can be handled by the
generated servlet or some other module )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Input optimization
Posted by Chris Brown <br...@reflexe.fr>.
> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.
prepend() ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Input optimization
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Great !
If you could come up with a better name for the "substract" method ;-)
It's supposed to be the opposite of append.
The optimization works good. It should help WebDAV as well as web
services, as long as they use the Tomcat reader.
Hopefully, I'll be able to write the new mapper soon, and TC 5 should
easily beat 4.1 in benchmarks.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Input optimization
Posted by Costin Manolache <cm...@yahoo.com>.
Great !
Costin
Remy Maucherat wrote:
> I've committed input optimization similar to the OutputBuffer used in
> the Coyote adapter. It appears to work ok (although
> BufferedWriter.readLine still needs to be implemented).
>
> I'm against porting this patch to 4.1.x, as it is a risky change (which
> will need lots of testing) with only a few cases where it would improve
> performance in the real world (InputStream performance is almost
> equivalent, and it is used a lot more often than the BufferedReader, as
> the integrated FORM POST parsing uses it).
>
> Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>