tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [5.0] Input optimization
Date Sun, 05 Jan 2003 21:34:27 GMT
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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message