[EMAIL PROTECTED] wrote:
>> -----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.
In my Jetspeed setup, I noticed that a hotspot for execution is the
URLEncoder.encode() calls
in renderPathInfo and renderQueryString methods of DynamicURI(under Sun jdk1.3).
They allocate a lot of memory internally to encode every portion of the
pathInfo, and every value of the query string.
Each call to URLEncoder.encode() allocates a StringBuffer() AND a
ByteArrayOutputStream(10), plus a String
with the final result is allocated at the end of the method.
As we call encode(str) inside a loop for each query string value and path info
componet,
they allocate a lot of objects.
It is difficult to handle this without reimplementing and serializing access to the
encoder,
but it could be worth..., possibly implementing a encoder internal to DynamicURI.
I have not done anything about it as it looks tricky and will made code less clean.
>>> 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.
>>
If this was done, it would benefit a lot of a internal encoder that
would encode urls to the writer/outputstream on the fly.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
