Re: JavaMemberNode optimisation

This change caused a slight side-effect: causeway does this:

  def editorShellListener :ShellListener := def _ { ... }
  
  editorShell.addShellListener(editorShellListener)
  ...
  editorShell.removeShellListener(editorShellListener)

This relies on editorShellListener being the same (deflector) object
each time. However, E.as always unwraps the deflector and creates a new
one.

The optimisation of trying the call first without coercing the arguments
allowed that to work (although it wouldn't have worked in other cases,
e.g. if there was a second argument that did need coercion).

Here's a possible fix:

  http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/70c46e2a2b5800f3228303f9feb1dbb7295d6813

It doesn't cover all cases (e.g. a SwitchableRef pointing at a
deflector) but it does cover the case that used to work. Once we have a
compiler, we should be able to do this (no deflector will be needed):

    def editorShellListener implements ShellListener { ... }


On Tue, 2010-09-14 at 08:36 -0700, Mark S. Miller wrote:
> Hi Thomas, I never measured the effect of this "optimization"; I was
> working only from a (flawed) intuition. Your patch looks good to me.
> 
> On Tue, Sep 14, 2010 at 8:23 AM, Thomas Leonard
> <tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]> wrote:
>         This patch makes my program run about 20% faster by disabling
>         an
>         "optimisation" in JavaMemberNode.
>         
>         I propose to apply it; does anyone have a test-case where the
>         optimisation actually helps?



-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk