Hi, this may be related but I don't know the code you're talking about and any profiling you may have done but I'm gonna throw this into the mix anyway.....
Guessing URLEncoder is used to generate URLs in your app. If you want a potentially big performance gain I suggest taking a look at this NewURLEncoder on the sun bug parade to replace Sun's heavy handed implementation shipped in the jdks:
http://developer.java.sun.com/developer/bugParade/bugs/4731779.html
(btw you have to sign in or register at the bug parade to see - but its worth the effort)
Have tested the code and like the guy says in the bug listing, NewURLEncoder is considerably faster than Java 1.3.x's and __MASSIVELY__ faster than Java 1.4.x's URLEncoder.
Hope this helps,
Eliot
> -----Original Message-----
> From: Dick Zetterberg [mailto:[EMAIL PROTECTED]]
> Sent: 08 October 2003 14:02
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] URLBean performance issues
>
>
> Not creating a new HashMap all the time sounds like a good
> idea. I'd prefer to have it created lazily though so that it
> is not created when it is not needed (when you do not have
> any parameters for example). Concerning the StringBuffer
> re-use: Did you measure the performance gain that you got
> from that? Since the buffer will be set to shared when the
> toString() method is called it means that the
> StringBuffer.delete method will need to copy the buffer, so
> there will be some overhead there anyway.
>
> Best regards,
>
> Dick Zetterberg
> [EMAIL PROTECTED]
>
> ----- Original Message -----
> From: "boxed" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, October 07, 2003 9:54 AM
> Subject: [OS-webwork] URLBean performance issues
>
>
> > I have a pretty large velocity page that needs to generate a lot of
> > urls, and I noticed that the roughly 4000 urls generated with the
> > URLBean class took about two seconds to generate. I took a
> look at the
> > code and saw that it creates and throws away a StringBuffer AND a
> > HashMap every single iteration. The URLTag class has the exact same
> > issue (since it's a copy paste instead of a reuse of the same code,
> > blech). I have attached the updated code, which is roughly
> twice as fast
> > on this perticular page at least.
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
> ______________________________________________________________
> __________
> This email has been scanned for all viruses by the
> MessageLabs service.
>
