I really like Berin's suggestion re Requests. The only con, that Leo
already mentioned, is an extra indirection level and growth of the
code that uses such new component managers.
>>>>> "Peter" == Peter Donald <[EMAIL PROTECTED]> writes:
>> That's a lot of Generator.ROLE + "/fooo"!
Peter> Put the key in a static at top of class (or cache it in
Peter> some other way) and that would be a lil better. Though
Peter> caching all strings would be a much better improvement
Peter> IMHO.
You still pay the price of hashing the string on lookups. I don't
think they keep the hash value in the String once calculated. And
since String is a final class you can't do anything about that.
Peter> Can you give me one solid reason why it needs to be done at
Peter> runtime in 99% of cases? I will grant you that runtime
Peter> assembly may be necessary when components looked up are
Peter> determined by request data but in other cases?
The component in question needs to be:
* expensive to construct
* single threaded
* often used for short periods of time
Can anybody name such a component? Something similar to a database
server will do ;-)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
