The thread local is near perfect.
There are no buckets created for that hashmap at all.
And that is also what they are saying! If you create ThreadLocals in sequence for one thread without to many other threads also creating one then it is near perfect hash.
And i just tested it with our app

At max right before we clean everything again there are 5 thread locals in the map. 3 of wicket: Application, Session, RequestCycle. and 2 of java or tomcat itself (StringCharset coding stuff)
And those 5 are perfectly divided in the 16 slots the map has.

So the only thing (computed) that is done is this in the get:

            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e.value;

And i don't think that can even be nicely measured if if you would ask it 20k times.

johan


On 12/7/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
even if the hashcode is optimal, it still depends on how many buckets you have in your hashmap. an optimal hashcode only guarantess that your search time is closer to O(log n) as opposed to O(n+log n). Now if you have Integer.MAX_SIZE buckets and a perfect hashing function,  then you are close to an index lookup but i dont think a threadlocal does that.

but i also agree, we can reduce complexity with insignificant effect on peformance.

-Igor



On 12/6/05, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
Unfortunately, if you remove that code from Component, junit tests
fail. That completely sucks as it should never have such side effects
to change internals. Let's fix it.

Eelco


On 12/6/05, Johan Compagner < [EMAIL PROTECTED]> wrote:
> if the page is a few parents deep then i think it will be slower.
>
> 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
> >
>
>


-------------------------------------------------------
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


Reply via email to