> -----Original Message-----
> From: ext Sean Legassick [mailto:[EMAIL PROTECTED]]
> Sent: 17. February 2001 15:55
> To: Turbine
> Subject: Re: [IDEA] Handling of DynamicURIs.
>
>
> On Fri, Feb 16, 2001 at 10:03:19AM -0800, John McNally wrote:
> > Santiago Gala wrote:
> > >
> > > While working on a patch to simplify current Jetspeed
> code, two ideas
> > > came up on me:
> > >
> > > 1- DynamicURI is a strong candidate for pooling
> instances, since it
> > > should be heavily used under most setups (typically, we
> have more than
> > > five per request, and they are instantiated afresh in
> every request). I
> > > imagine you have already considered this object.
> > >
> >
> > It is at least as good a candidate as the ParameterParser. I think
> > DynamicURI should be made an interface. DynamicURI/ParameterParser
> > paired implementations could then be used to alter the
> > uri format that we currently use. Not that I feel our
> implementation
> > needs improvement per se, but I have seen others such as
> what's in Tea
> > that might be of interest.
>
> Agreed, +1 on pooling both DynamicURI and ParameterParser instances.
> And making them both interfaces with pluggable implementations is
> certainly an interesting idea...
Yes, +1 for interfaces/pluggable implementations as it would help to use
Turbine for different mobile protocols, like SMS, WAP, IMODE, JSKY, etc.,
some of which need customized parsing as they do not support all features of
HTTP. This area covers also many template related topics, but we're still
working on them...
Pooling wouldn't provide so much benefits as it seemed at the first glance.
DynamicURI has two Vectors and ParameterParser one Hashtable that are
allocated dynamically. The other memory consumers are mainly local variables
within methods, which can't be pooled. If both classes were explicitly
restricted to be used within a single thread only (as at least
ParameterParser implicitly is when used through the RunData), some of the
local variables could be changed to class variables, which would decrease
memory consumption together with pooling. At the same time, Vectors could be
changed to ArrayLists and Hashtables to HashMaps, which would reduce
synchronization.
FormMessages is another memory consumer in TurbineRunData. It allocates four
Hashtables during its intantiation and it's intantiated for every request.
Maybe it should be intantiated only when really used, Hashtables changed to
HashMaps and pooled together with TurbineRunData?
> > 2- It could give an efficience boost if we could change the way it is
> > used. Instead of returning it as a String, we could have something like
> > dynuri.write( data.getWriter() ); , writing it straight into the
> > response. This would save some StringBuffer and String instantiations
> > ---> less garbage ---> better memory efficience again.
The possibility to manipulate the URI before sending maybe outweighs the
perfomance improvement gained by the writer. It's possible to reuse
Strings/StringBuffers defined as class variables, or to use one byte array
instead of several Strings/StringBuffers.
-- Ilkka
--
Nokia Networks
http://www.nokia.com/networks
mail: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
