Re: [Swig-devel] Making Java directors more efficient in the case where methods are expected to be overridden.

[William S F. <ws...@fu...>]

Hi David,

That looks fine to me. Thanks for the test case and docs. I'll test it 
and commit it before swig-2.0.8 is released.

William

On 08/08/12 18:40, David Baum wrote:
> Here's a patch with the assumeoverride option.  Does this all seem
> reasonable?  This was my first delve into swig's source, so if there's a
> more appropriate way to check attributes, etc. please let me know.
>
> Dave
>
> On Tue, Jul 17, 2012 at 12:58 AM, William S Fulton
> <ws...@fu... <mailto:ws...@fu...>> wrote:
>
>     On 13/07/12 23:22, David Baum wrote:
>
>         We're using directors in a fairly unusual situation: we
>         instantiate many
>         objects derived from the Java base class and we generally expect the
>         base behavior to be overridden in Java.  Although the virtual
>         interface
>         has 6 methods declared, the typical use case is to call at most
>         one of
>         these methods, although which one depends on runtime data.
>
>         It turns out that the GetMethodID() calls within
>         swig_connect_director()
>         are consuming a noticeable amount of CPU time.  I believe the
>         proxy code
>         (as of 1.3.40) is safe with respect to infinite loops which means
>         setting swig_override[x] to be true will always result in correct
>         behavior, although it is very inefficient if there actually is no
>         override in Java.  As such, the calls to GetMethodID() are certainly
>         justified when overrides aren't nearly universal and/or invocations
>         significantly outnumber instantiations.
>
>         However in our case this optimization is actually costing us
>         time.  I'd
>         like to add an additional parameter, something like this:
>
>         %feature("director", assume_override=1)
>
>         Java code generation when assume_override is set would simply assign
>         swig_override[x]=true rather than invoking GetMethodID().
>
>         Does this sound like something that can be merged into the main swig
>         release?  If so, what steps should I take to start this work?  The
>         change itself is rather modest, but I assume you will want tests,
>         documentation, etc.  I'm also not thrilled with
>         "assume_override" as the
>         name - any other suggestion would be fine.
>
>
>     This sounds like a reasonable feature option for general release. A
>     new testcase for the test-suite and a some documentation would be
>     required please and shouldn't be too onerous. Please look at the
>     other Examples/director_* testcases.
>     http://www.swig.org/Doc2.0/__Extending.html#Extending_test___suite
>     <http://www.swig.org/Doc2.0/Extending.html#Extending_test_suite>
>     should be helpful. A patch with all of this would be the final step
>     for submission.
>
>     With regard to names, a single word would be better, but I can't
>     think of a better name. Only thing is the naming convention - we
>     don't use underscores in feature names/options, so I would just go
>     with "assumeoverride" or "assumeoverridden".
>
>     William
>
>