On Thu, Apr 21, 2011 at 4:53 AM, Clifford Heath <no / spam.please.net> wrote:

> On 04/20/11 08:41, Charles Oliver Nutter wrote:

>> I think you are underestimating the cost of performing a dynamic call.
>
> I'm not. I'm expecting that JRuby would detect that a core Fixnum
> method has been monkey-patched, and set a global variable. If  ¨Âèå
> variable is set (an inline check, susceptible to branch-prediction)
> then it would default to conservative behaviour by calling dispatch,
> otherwise continue with the shortcuts as normal.

> The cost of the inline check of this variable is what I was implying
> would vanish into the dust in performance tests, as the branch
> prediction figures out that "we always go this way".

Please keep in mind that in a multithreaded environment there is
synchronization overhead.  A solution could use an AtomicBoolean
stored somewhere as static final.  Now all threads that need to make
the decision need to go through this.  Even if it is "only" volatile
semantics (and not synchronized) and allows for concurrent reads there
is a price to pay.  Using a ThreadLocal which is initialized during
thread construction or lazily would reduce synchronization overhead at
the risk of the flag value becoming outdated - an issue which becomes
worse with thread lifetime.  Applications which use a thread pool
could suffer.

But I agree, the effect vastly depends on the frequency of Hash
accesses with a Fixnum key.  Unfortunately I guess nobody has figures
about this - and even if, those will probably largely vary with type
of application.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/