I think the fear that some have for thread local access is not needed
Hashmap lookups one thing can slow it down and that is that the hashcode needs to be computed
and that the hashcode is bad so we create a hashmap that has many buckets in one place (linked list on an index)
But with thread locals this is not the case. Hashcode is computed onces when you make a threadlocal
And the hashcode that is generated is i now copy there words:
/**
* The difference between successively generated hash codes - turns
* implicit sequential thread-local IDs into near-optimally spread
* multiplicative hash values for power-of-two-sized tables.
*/
So there are almost no buckets it is pure a index lookup..
If it was me then we could remove all those caching things and use thread local access for everything.
johan
On 12/7/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
This is part of Component.java
public final Session getSession()
{
// Fetch page, if possible
final Page page = findPage();
// If this component is attached to a page
if (page != null)
{
// Get Session from Page (which should generally be
// faster than a thread local lookup via Session.get())
return page.getSessionInternal();
}
else
{
// Use ThreadLocal storage to get Session since this
// component is apparently not yet attached to a Page.
return Session.get();
}
}
I wonder if component.findPage() is realy more efficient than a
hashmap access by the ThreadLocal. Is there any other reason besides
performance for this construct?
Juergen
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
