SWIG

Please try the CVS version, there are some critical fixes for the 
runtime library + the import
mechanism. If that doesn't fix the problem, we will need you to try to 
reproduce the problem
with a small example we can play with here.

thanks,

Marcelo


Robin Dunn wrote:

> Hi,
>
> I'm upgrading from 1.3.24 to 1.3.27 and have run into a problem with 
> the new runtime, specifically, I think, with the initialization of the 
> type info structures.
>
> Here is the situation:  In the _core module I have these classes, 
> along with a bunch of other stuff:
>
>     class wxObject
>     class wxEvtHandler : public wxObject
>     class wxWindow : public wxEvtHandler
>
> In the _windows module I have this:
>
>     class wxFrame : public wxWindow
>
> And I have added code to the _core.py module to always import 
> _windows.py, so both of them are always imported together along with a 
> few others.  (I had to split the "core" into multiple modules because 
> of the large size of the generated source code files.)
>
> Now here is the problem.  In the _core module there is a method that 
> returns a wxFrame*, so there is a _swigt__p_wxFrame and 
> _swigc__p_wxFrame generated for it, but since swig doesn't know about 
> how it fits in the heirarchy it doesn't specify any typecast functions 
> for it in _core.  In 1.3.24 this didn't cause a problem because it 
> would get updated when the _windows module was imported.  Now 
> SWIG_InitializeModule is making the assumption that if there is 
> already a known swig_type for a cast that it doesn't need to update 
> the type's cast list with that particular cast.  So in this case I end 
> up with the casts for wxEvtHandler not having an entry for wxFrame, 
> and so calling a function that takes a wxEvtHandler and passing a 
> wxFrame results in a TypeError.
>
> So I guess my questions are, is this a known problem?  Is there a 
> convenient workaround?  Is there a fix already in CVS?
>
> I guess that this is case #2 in the comment before the 
> SWIG_InitializeModule function, but instead of just ignoring the new 
> cast info as it says I think that there should be the possibility of 
> updating the cast info because what is already there may be 
> incomplete.  Thoughts?
>

Marcelo Matus wrote:
> Please try the CVS version, there are some critical fixes for the 
> runtime library + the import
> mechanism. If that doesn't fix the problem, we will need you to try to 
> reproduce the problem
> with a small example we can play with here.

Something like the attached should show it.  (Not completely tested, but 
I verified that the code has the same "feature" I was seeing in the 
debugger earlier.)

The wrap file for mod1 gets these lines:

static swig_cast_info _swigc__p_A[] = {  {&_swigt__p_A, 0, 0, 0}, 
{&_swigt__p_B, _p_BTo_p_A, 0, 0},{0, 0, 0, 0}};
static swig_cast_info _swigc__p_B[] = {  {&_swigt__p_B, 0, 0, 0},{0, 0, 
0, 0}};
static swig_cast_info _swigc__p_C[] = {  {&_swigt__p_C, 0, 0, 0},{0, 0, 
0, 0}};


And the mod2 wrapper gets these lines:

static swig_cast_info _swigc__p_A[] = {  {&_swigt__p_A, 0, 0, 0}, 
{&_swigt__p_B, _p_BTo_p_A, 0, 0},  {&_swigt__p_C, _p_CTo_p_A, 0, 0}, 
{&_swigt__p_D, _p_DTo_p_A, 0, 0},{0, 0, 0, 0}};
static swig_cast_info _swigc__p_B[] = {  {&_swigt__p_B, 0, 0, 0}, 
{&_swigt__p_C, _p_CTo_p_B, 0, 0},  {&_swigt__p_D, _p_DTo_p_B, 0, 0},{0, 
0, 0, 0}};
static swig_cast_info _swigc__p_C[] = {  {&_swigt__p_C, 0, 0, 0}, 
{&_swigt__p_D, _p_DTo_p_C, 0, 0},{0, 0, 0, 0}};
static swig_cast_info _swigc__p_D[] = {  {&_swigt__p_D, 0, 0, 0},{0, 0, 
0, 0}};


When mod2 is imported and SWIG_InstallModule runs it doesn't add the 
converter for C to the list of typecasts for A because swig is already 
aware of the C type.

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!

Robin Dunn wrote:
> Marcelo Matus wrote:
>> Please try the CVS version, there are some critical fixes for the 
>> runtime library + the import
>> mechanism. If that doesn't fix the problem, we will need you to try to 
>> reproduce the problem
>> with a small example we can play with here.
> 
> Something like the attached should show it. 

I forgot to mention that the CVS version does still have the problem.

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!

Ok, try it now again.

Marcelo


Robin Dunn wrote:

> Robin Dunn wrote:
>
>> Marcelo Matus wrote:
>>
>>> Please try the CVS version, there are some critical fixes for the 
>>> runtime library + the import
>>> mechanism. If that doesn't fix the problem, we will need you to try 
>>> to reproduce the problem
>>> with a small example we can play with here.
>>
>>
>> Something like the attached should show it. 
>
>
> I forgot to mention that the CVS version does still have the problem.
>

It does work with the new version of swiginit.swg, however it now can 
end up with duplicate cast converters in the list.  Is it worth the 
extra startup-time to not add casts if there is already a matching one 
in the list?

FYI, to easily see and test this I added wrappers for swig_type_info and 
swig_cast_info and used the attached test script, and got this output:


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test: wxEvtHandler*, after importing _core
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
9 items
['_p_wxControl',
  '_p_wxControlWithItems',
  '_p_wxEvtHandler',
  '_p_wxMenu',
  '_p_wxMenuBar',
  '_p_wxPyApp',
  '_p_wxPyValidator',
  '_p_wxValidator',
  '_p_wxWindow']

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test: wxEvtHandler*, after importing _windows
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
59 items
['_p_wxColourDialog',
  '_p_wxControl',
  '_p_wxControl',
  '_p_wxControlWithItems',
  '_p_wxControlWithItems',
  '_p_wxDialog',
  '_p_wxDirDialog',
  '_p_wxEvtHandler',
  '_p_wxEvtHandler',
  '_p_wxFileDialog',
  '_p_wxFindReplaceDialog',
  '_p_wxFontDialog',
  '_p_wxFrame',
  '_p_wxMDIChildFrame',
  '_p_wxMDIClientWindow',
  '_p_wxMDIParentFrame',
  '_p_wxMenu',
  '_p_wxMenu',
  '_p_wxMenuBar',
  '_p_wxMenuBar',
  '_p_wxMessageDialog',
  '_p_wxMiniFrame',
  '_p_wxMultiChoiceDialog',
  '_p_wxPanel',
  '_p_wxPasswordEntryDialog',
  '_p_wxPopupWindow',
  '_p_wxPreviewCanvas',
  '_p_wxPreviewControlBar',
  '_p_wxPreviewFrame',
  '_p_wxProgressDialog',
  '_p_wxPyApp',
  '_p_wxPyApp',
  '_p_wxPyHtmlListBox',
  '_p_wxPyPanel',
  '_p_wxPyPopupTransientWindow',
  '_p_wxPyPreviewControlBar',
  '_p_wxPyPreviewFrame',
  '_p_wxPyScrolledWindow',
  '_p_wxPyTaskBarIcon',
  '_p_wxPyVListBox',
  '_p_wxPyVScrolledWindow',
  '_p_wxPyValidator',
  '_p_wxPyValidator',
  '_p_wxPyWindow',
  '_p_wxSashLayoutWindow',
  '_p_wxSashWindow',
  '_p_wxScrolledWindow',
  '_p_wxSingleChoiceDialog',
  '_p_wxSplashScreen',
  '_p_wxSplashScreenWindow',
  '_p_wxSplitterWindow',
  '_p_wxStatusBar',
  '_p_wxTextEntryDialog',
  '_p_wxTipWindow',
  '_p_wxTopLevelWindow',
  '_p_wxValidator',
  '_p_wxValidator',
  '_p_wxWindow',
  '_p_wxWindow']


Robin



Marcelo Matus wrote:
> Ok, try it now again.
> 
> Marcelo
> 
> 
> Robin Dunn wrote:
> 
>> Robin Dunn wrote:
>>
>>> Marcelo Matus wrote:
>>>
>>>> Please try the CVS version, there are some critical fixes for the 
>>>> runtime library + the import
>>>> mechanism. If that doesn't fix the problem, we will need you to try 
>>>> to reproduce the problem
>>>> with a small example we can play with here.
>>>
>>>
>>> Something like the attached should show it. 
>>
>>
>> I forgot to mention that the CVS version does still have the problem.
>>

Try it again please.

marcelo


Robin Dunn wrote:

> It does work with the new version of swiginit.swg, however it now can 
> end up with duplicate cast converters in the list.  Is it worth the 
> extra startup-time to not add casts if there is already a matching one 
> in the list?
>
> FYI, to easily see and test this I added wrappers for swig_type_info 
> and swig_cast_info and used the attached test script, and got this 
> output:
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test: wxEvtHandler*, after importing _core
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 9 items
> ['_p_wxControl',
>  '_p_wxControlWithItems',
>  '_p_wxEvtHandler',
>  '_p_wxMenu',
>  '_p_wxMenuBar',
>  '_p_wxPyApp',
>  '_p_wxPyValidator',
>  '_p_wxValidator',
>  '_p_wxWindow']
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test: wxEvtHandler*, after importing _windows
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 59 items
> ['_p_wxColourDialog',
>  '_p_wxControl',
>  '_p_wxControl',
>  '_p_wxControlWithItems',
>  '_p_wxControlWithItems',
>  '_p_wxDialog',
>  '_p_wxDirDialog',
>  '_p_wxEvtHandler',
>  '_p_wxEvtHandler',
>  '_p_wxFileDialog',
>  '_p_wxFindReplaceDialog',
>  '_p_wxFontDialog',
>  '_p_wxFrame',
>  '_p_wxMDIChildFrame',
>  '_p_wxMDIClientWindow',
>  '_p_wxMDIParentFrame',
>  '_p_wxMenu',
>  '_p_wxMenu',
>  '_p_wxMenuBar',
>  '_p_wxMenuBar',
>  '_p_wxMessageDialog',
>  '_p_wxMiniFrame',
>  '_p_wxMultiChoiceDialog',
>  '_p_wxPanel',
>  '_p_wxPasswordEntryDialog',
>  '_p_wxPopupWindow',
>  '_p_wxPreviewCanvas',
>  '_p_wxPreviewControlBar',
>  '_p_wxPreviewFrame',
>  '_p_wxProgressDialog',
>  '_p_wxPyApp',
>  '_p_wxPyApp',
>  '_p_wxPyHtmlListBox',
>  '_p_wxPyPanel',
>  '_p_wxPyPopupTransientWindow',
>  '_p_wxPyPreviewControlBar',
>  '_p_wxPyPreviewFrame',
>  '_p_wxPyScrolledWindow',
>  '_p_wxPyTaskBarIcon',
>  '_p_wxPyVListBox',
>  '_p_wxPyVScrolledWindow',
>  '_p_wxPyValidator',
>  '_p_wxPyValidator',
>  '_p_wxPyWindow',
>  '_p_wxSashLayoutWindow',
>  '_p_wxSashWindow',
>  '_p_wxScrolledWindow',
>  '_p_wxSingleChoiceDialog',
>  '_p_wxSplashScreen',
>  '_p_wxSplashScreenWindow',
>  '_p_wxSplitterWindow',
>  '_p_wxStatusBar',
>  '_p_wxTextEntryDialog',
>  '_p_wxTipWindow',
>  '_p_wxTopLevelWindow',
>  '_p_wxValidator',
>  '_p_wxValidator',
>  '_p_wxWindow',
>  '_p_wxWindow']
>
>
> Robin
>
>
>
> Marcelo Matus wrote:
>
>> Ok, try it now again.
>>
>> Marcelo
>>
>>
>> Robin Dunn wrote:
>>
>>> Robin Dunn wrote:
>>>
>>>> Marcelo Matus wrote:
>>>>
>>>>> Please try the CVS version, there are some critical fixes for the 
>>>>> runtime library + the import
>>>>> mechanism. If that doesn't fix the problem, we will need you to 
>>>>> try to reproduce the problem
>>>>> with a small example we can play with here.
>>>>
>>>>
>>>>
>>>> Something like the attached should show it. 
>>>
>>>
>>>
>>> I forgot to mention that the CVS version does still have the problem.
>>>
>
>
>------------------------------------------------------------------------
>
>
>from pprint import pprint as pp
>
>def testit(msg, klass="wxEvtHandler*"):
>    info = _core.SWIG_TypeQuery(klass)
>    cast = info.cast
>    lst = []
>    while cast:
>        lst.append(cast.type.name)
>        cast = cast.next
>
>    lst.sort()
>    print
>    print '-='*30
>    print 'Test: %s, %s' % (klass, msg)
>    print '-='*30
>    print len(lst), "items"
>    pp(lst)
>
>
>import _core
>testit('after importing _core')
>
>import _windows
>testit('after importing _windows')
>
>  
>

Some comments:

The duplication seems to be resolved now. But....

In the last modifications to the runtime library, John Lenz added a 
binary search for types,
but the cast info still seems to be a plain list. In mos of the cases, 
that should be fine, but
in large type systems, probably that will create some performance 
issues. The think is
I am not sure how "large" the type systems has to be for you to see the 
problem,  even
more now that we hardly call SWIG_TypeQuery (at least in python).... 
anyway, this is
a research topic for an interested CS student.

Marcelo


Robin Dunn wrote:

> It does work with the new version of swiginit.swg, however it now can 
> end up with duplicate cast converters in the list.  Is it worth the 
> extra startup-time to not add casts if there is already a matching one 
> in the list?
>
> FYI, to easily see and test this I added wrappers for swig_type_info 
> and swig_cast_info and used the attached test script, and got this 
> output:
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test: wxEvtHandler*, after importing _core
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 9 items
> ['_p_wxControl',
>  '_p_wxControlWithItems',
>  '_p_wxEvtHandler',
>  '_p_wxMenu',
>  '_p_wxMenuBar',
>  '_p_wxPyApp',
>  '_p_wxPyValidator',
>  '_p_wxValidator',
>  '_p_wxWindow']
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test: wxEvtHandler*, after importing _windows
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 59 items
> ['_p_wxColourDialog',
>  '_p_wxControl',
>  '_p_wxControl',
>  '_p_wxControlWithItems',
>  '_p_wxControlWithItems',
>  '_p_wxDialog',
>  '_p_wxDirDialog',
>  '_p_wxEvtHandler',
>  '_p_wxEvtHandler',
>  '_p_wxFileDialog',
>  '_p_wxFindReplaceDialog',
>  '_p_wxFontDialog',
>  '_p_wxFrame',
>  '_p_wxMDIChildFrame',
>  '_p_wxMDIClientWindow',
>  '_p_wxMDIParentFrame',
>  '_p_wxMenu',
>  '_p_wxMenu',
>  '_p_wxMenuBar',
>  '_p_wxMenuBar',
>  '_p_wxMessageDialog',
>  '_p_wxMiniFrame',
>  '_p_wxMultiChoiceDialog',
>  '_p_wxPanel',
>  '_p_wxPasswordEntryDialog',
>  '_p_wxPopupWindow',
>  '_p_wxPreviewCanvas',
>  '_p_wxPreviewControlBar',
>  '_p_wxPreviewFrame',
>  '_p_wxProgressDialog',
>  '_p_wxPyApp',
>  '_p_wxPyApp',
>  '_p_wxPyHtmlListBox',
>  '_p_wxPyPanel',
>  '_p_wxPyPopupTransientWindow',
>  '_p_wxPyPreviewControlBar',
>  '_p_wxPyPreviewFrame',
>  '_p_wxPyScrolledWindow',
>  '_p_wxPyTaskBarIcon',
>  '_p_wxPyVListBox',
>  '_p_wxPyVScrolledWindow',
>  '_p_wxPyValidator',
>  '_p_wxPyValidator',
>  '_p_wxPyWindow',
>  '_p_wxSashLayoutWindow',
>  '_p_wxSashWindow',
>  '_p_wxScrolledWindow',
>  '_p_wxSingleChoiceDialog',
>  '_p_wxSplashScreen',
>  '_p_wxSplashScreenWindow',
>  '_p_wxSplitterWindow',
>  '_p_wxStatusBar',
>  '_p_wxTextEntryDialog',
>  '_p_wxTipWindow',
>  '_p_wxTopLevelWindow',
>  '_p_wxValidator',
>  '_p_wxValidator',
>  '_p_wxWindow',
>  '_p_wxWindow']
>
>
> Robin
>
>
>
> Marcelo Matus wrote:
>
>> Ok, try it now again.
>>
>> Marcelo
>>
>>
>> Robin Dunn wrote:
>>
>>> Robin Dunn wrote:
>>>
>>>> Marcelo Matus wrote:
>>>>
>>>>> Please try the CVS version, there are some critical fixes for the 
>>>>> runtime library + the import
>>>>> mechanism. If that doesn't fix the problem, we will need you to 
>>>>> try to reproduce the problem
>>>>> with a small example we can play with here.
>>>>
>>>>
>>>>
>>>> Something like the attached should show it. 
>>>
>>>
>>>
>>> I forgot to mention that the CVS version does still have the problem.
>>>
>
>
>------------------------------------------------------------------------
>
>
>from pprint import pprint as pp
>
>def testit(msg, klass="wxEvtHandler*"):
>    info = _core.SWIG_TypeQuery(klass)
>    cast = info.cast
>    lst = []
>    while cast:
>        lst.append(cast.type.name)
>        cast = cast.next
>
>    lst.sort()
>    print
>    print '-='*30
>    print 'Test: %s, %s' % (klass, msg)
>    print '-='*30
>    print len(lst), "items"
>    pp(lst)
>
>
>import _core
>testit('after importing _core')
>
>import _windows
>testit('after importing _windows')
>
>  
>

On Fri, January 20, 2006 2:42 pm, Marcelo Matus said:
> Some comments:
>
> The duplication seems to be resolved now. But....
>
> In the last modifications to the runtime library, John Lenz added a
> binary search for types,
> but the cast info still seems to be a plain list. In mos of the cases,
> that should be fine, but
> in large type systems, probably that will create some performance
> issues. The think is
> I am not sure how "large" the type systems has to be for you to see the
> problem,  even
> more now that we hardly call SWIG_TypeQuery (at least in python)....
> anyway, this is
> a research topic for an interested CS student.
>
> Marcelo
>

A looked at this a while back... the main problem was the O(n^2) during
module init, which is now at N log N.  Your addition of that code in
swiginit.swg boosts the complexity back to N^2.

Since we were accessing the list of types inside another list, using a
binary search lowered us from n^2 to n log n.  On the other hand, the cast
info was usually only accessed from the _wrap function, and it only walks
the list once.  So sorting the list would only decreace from N to log N,
with the added cost of having to do the sort at run-time instead of during
swig generation time.  Secondly, the cast information can be accessed
multiple ways (by name, by address, by some perl thing i can't quite
remember right now) so you would need to do some sort of hashtable, one
for each lookup key...

I'll have to take a closer look at this, but I think we might need some
way to get back to N log N on the init.  I dislike increacing the
complexity of the loading for this corner case.

The problem is that two types do not appear to be connected while parsing
mod1, but get connected in mod2.  Because of types being used before they
are declared.  This becomes a slightly bigger problem, because if mod2 is
not loaded, then types A and C are not connected at all.  In theory, you
could use only mod1 and expect that something returned from getC be
passable to A functions.  I would think that the correct solution is to
tell mod1 that A and C are connected to each other, and generate an error
if mod2 connects two types that were not connected in an %imported module.
 Because consider the case where I create a mod3.i

%{
#include "mod.h"
%}

typedef B C;

class E {
  void doSomeStuff(C *c);
};

and then declare in mod.h
class E {
  void doSomeStuff(B *b);
}

Since C is just an empty class, the interfaces wouldn't care.  Or assume
that class C consists only of overridden virtual functions, and does not
include any new functions or defs.... then the wrapper code will still
work just fine, even though we declared C differently in two different
modules.

Before, this type of code would just fail.... we should probably have
added an error or warning that it was happening, but now, the connection
between B and C will be messed up... can a B be converted into a C?  The
only place that knows that is mod.h....

The question is, the run time code can not sort this out without knowing
what "really" happens in mod.h.  There are a whole lot of ways to trick
the type system by telling it different stuff than what you are actually
wrapping, and hoping that the run time type code can put it all back
together is not really viable.  I have tried to keep the run time code as
simple and stupid as possible.

So rather than add smarts into the run time code, I would rather force
SWIG  to correctly "know" while parsing mod1 that types A and C are
connected, and error if mod2 connects them without mod1 knowing about
it....

The simplest way to do this would be to add a %import "mod2.i" to the
bottom of mod1.i.  Then the mod1 type table correctly exports the
connection between A and C.  The only downside is it exports the type D
too, making the module a little bit bigger.... but going back to a N log N
importing makes this a small concern.  If it was, we would just need to
improve the detection that a type is not actually used anywhere, or add a
%removetype D code or something.

John

On Thu, January 19, 2006 8:26 pm, Robin Dunn said:
> Marcelo Matus wrote:
>> Please try the CVS version, there are some critical fixes for the
>> runtime library + the import
>> mechanism. If that doesn't fix the problem, we will need you to try to
>> reproduce the problem
>> with a small example we can play with here.
>
> Something like the attached should show it.  (Not completely tested, but
> I verified that the code has the same "feature" I was seeing in the
> debugger earlier.)

This is a simple fix of adding %import "mod2.i" to the bottom of mod1.i,
and I would favor that solution over adding smarts into the run time type
system to detect things you didn't tell SWIG about.


>
> When mod2 is imported and SWIG_InstallModule runs it doesn't add the
> converter for C to the list of typecasts for A because swig is already
> aware of the C type.
>

The easist way is to just tell mod1 about the connection, so mod1 knows
everything about type C.

John

John Lenz wrote:

>On Fri, January 20, 2006 2:42 pm, Marcelo Matus said:
>  
>
>>Some comments:
>>
>>The duplication seems to be resolved now. But....
>>
>>In the last modifications to the runtime library, John Lenz added a
>>binary search for types,
>>but the cast info still seems to be a plain list. In mos of the cases,
>>that should be fine, but
>>in large type systems, probably that will create some performance
>>issues. The think is
>>I am not sure how "large" the type systems has to be for you to see the
>>problem,  even
>>more now that we hardly call SWIG_TypeQuery (at least in python)....
>>anyway, this is
>>a research topic for an interested CS student.
>>
>>Marcelo
>>
>>    
>>
>
>A looked at this a while back... the main problem was the O(n^2) during
>module init, which is now at N log N.  Your addition of that code in
>swiginit.swg boosts the complexity back to N^2.
>  
>

well, the point is that in practice is far simpler than the worst case 
N^2, since to avoid
cast repetitions we navigate the cast lists, not the type info 
structures, and if we
have N types,  we never have N cast list of length N. For example, in
the PyICU system they have around 350 types, where only around 20 cast list
have more than one element, and the largest cast list has around 30 
elements.

so, the worst case instead of N^2 is something like \sum_i^N Nc_i, where 
Nc_i is the 'i'
number of cast. Of course, in theory, the worst case will be Nc_i = 
{N-1,N-2,...}, but
in real cases, the larger the N, the 'simpler' the cast list are in 
average, most of them having
just 1 element, and a few more than that.


>Since we were accessing the list of types inside another list, using a
>binary search lowered us from n^2 to n log n.  On the other hand, the cast
>info was usually only accessed from the _wrap function, and it only walks
>the list once.  So sorting the list would only decreace from N to log N,
>with the added cost of having to do the sort at run-time instead of during
>swig generation time.  Secondly, the cast information can be accessed
>multiple ways (by name, by address, by some perl thing i can't quite
>remember right now) so you would need to do some sort of hashtable, one
>for each lookup key...
>  
>

don't worry, the perl issue was resolved "normalizing" its type 
information. The old way breaks
easily when you mix namespaces that break the 'sort' requirement. So, 
now all the type languages
use the same naming convention in the cast list.

So, in the worst case, we will need the same solution you have for the 
type info list.

>I'll have to take a closer look at this, but I think we might need some
>way to get back to N log N on the init.  I dislike increacing the
>complexity of the loading for this corner case.
>  
>

yes, please. but again, probably we need a couple of real huge type 
system for you to
play with, and check if you see any difference, since as I said, in 
practice, the larger is N,
the shorter in average are the cast lists.

>The problem is that two types do not appear to be connected while parsing
>mod1, but get connected in mod2.  Because of types being used before they
>are declared.  This becomes a slightly bigger problem, because if mod2 is
>not loaded, then types A and C are not connected at all.  In theory, you
>could use only mod1 and expect that something returned from getC be
>passable to A functions.  I would think that the correct solution is to
>tell mod1 that A and C are connected to each other, and generate an error
>if mod2 connects two types that were not connected in an %imported module.
> Because consider the case where I create a mod3.i
>
>%{
>#include "mod.h"
>%}
>
>typedef B C;
>
>class E {
>  void doSomeStuff(C *c);
>};
>
>and then declare in mod.h
>class E {
>  void doSomeStuff(B *b);
>}
>
>Since C is just an empty class, the interfaces wouldn't care.  Or assume
>that class C consists only of overridden virtual functions, and does not
>include any new functions or defs.... then the wrapper code will still
>work just fine, even though we declared C differently in two different
>modules.
>
>Before, this type of code would just fail.... we should probably have
>added an error or warning that it was happening, but now, the connection
>between B and C will be messed up... can a B be converted into a C?  The
>only place that knows that is mod.h....
>
>The question is, the run time code can not sort this out without knowing
>what "really" happens in mod.h.  There are a whole lot of ways to trick
>the type system by telling it different stuff than what you are actually
>wrapping, and hoping that the run time type code can put it all back
>together is not really viable.  I have tried to keep the run time code as
>simple and stupid as possible.
>
>So rather than add smarts into the run time code, I would rather force
>SWIG  to correctly "know" while parsing mod1 that types A and C are
>connected, and error if mod2 connects them without mod1 knowing about
>it....
>
>The simplest way to do this would be to add a %import "mod2.i" to the
>bottom of mod1.i.  Then the mod1 type table correctly exports the
>connection between A and C.  The only downside is it exports the type D
>too, making the module a little bit bigger.... but going back to a N log N
>importing makes this a small concern.  If it was, we would just need to
>improve the detection that a type is not actually used anywhere, or add a
>%removetype D code or something.
>
>  
>
the problem is, of course, you are asking the users to re-write the 
interfaces in a smarter way
to overcome the runtime library features.  the "mod" case is just a 
simple example where human
intervention will be needed, and that is a very simple case.

Things can be a lot worse, for example,  take a look at PyICU, they have 
around
10 modules and multiple cross imports, a lot of them to be specific. The 
last swig version
that worked with PyICU was 1.3.24. With the last changes in the runtime 
library PyICU is
working again, and no change was needed in the PyICU interfaces. And the 
init time is  really
neglectable.

So, if you plan to play with the runtime library a little more, which I 
welcome a lot,
at least we should establish a list of large "legacy" projects  that 
should keep running with no
extra human intervention, and since PyICU is a nice "multi-cross-import" 
case, I propose it as the
first in the list. You can also use it also as a benchmark case to see 
how fast the swig initialization
runs.

Marcelo

>John
>
>  
>

On Mon, 23 Jan 2006, Marcelo Matus wrote:

> well, the point is that in practice is far simpler than the worst case
> N^2, since to avoid cast repetitions we navigate the cast lists, not the
> type info structures, and if we have N types, we never have N cast list
> of length N. For example, in the PyICU system they have around 350
> types, where only around 20 cast list have more than one element, and
> the largest cast list has around 30 elements.

Why does SWIG supports more than two implicit casts, when even C++ itself
supports at most two (iirc), and most languages that have implicit casts
only do one?

When there are several possible cast-paths, how does SWIG pick which one=20
gets used? e.g. If I have types A,B,C,D and the following cast-matrix:

   A B C D
  ,-------
A |1 f h 0
B |0 1 0 g
C |0 0 1 w
D |0 0 0 1

then casting value x from type A to type D can be done both via B by
g(f(x)) and via C by w(h(x)). BTW here "1" means no cast needed and "0"
means not castable and rows are input types while columns are output=20
types.

Which one would be picked by SWIG, and most importantly, why?

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - t=E9l:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montr=E9al QC Canada

Mathieu Bouchard wrote:

>On Mon, 23 Jan 2006, Marcelo Matus wrote:
>
> =20
>
>>well, the point is that in practice is far simpler than the worst case
>>N^2, since to avoid cast repetitions we navigate the cast lists, not th=
e
>>type info structures, and if we have N types, we never have N cast list
>>of length N. For example, in the PyICU system they have around 350
>>types, where only around 20 cast list have more than one element, and
>>the largest cast list has around 30 elements.
>>   =20
>>
>
>Why does SWIG supports more than two implicit casts, when even C++ itsel=
f
>supports at most two (iirc), and most languages that have implicit casts
>only do one?
>
>When there are several possible cast-paths, how does SWIG pick which one=
=20
>gets used? e.g. If I have types A,B,C,D and the following cast-matrix:
>
>   A B C D
>  ,-------
>A |1 f h 0
>B |0 1 0 g
>C |0 0 1 w
>D |0 0 0 1
>
>then casting value x from type A to type D can be done both via B by
>g(f(x)) and via C by w(h(x)). BTW here "1" means no cast needed and "0"
>means not castable and rows are input types while columns are output=20
>types.
>
>Which one would be picked by SWIG, and most importantly, why?
> =20
>

The cast list that swig save refers to explicit cast, for example, if=20
you have:

  struct A {};
  struct B : A {};

swig save the relation or cast from B -> A, using a method like

   void* BtoA(void *ptr) { return  (A*) (B *)(ptr);}

so the limit for implicit casting doesn't apply. Of course, if you have=20
something like

  struct BaseClassForAll {};
  struct Foo : BaseClassForAll {};
  ....

then 'BaseClassForAll' will have a large cast list, and 'Foo' probably a=20
very short one
if is a 'terminal' class, ie, if it has no derived classes.


Marcelo

> _ _ __ ___ _____ ________ _____________ _____________________ ...
>| Mathieu Bouchard - t=E9l:+1.514.383.3801 - http://artengine.ca/matju
>| Freelance Digital Arts Engineer, Montr=E9al QC Canada
>
> =20
>

On Tue, 24 Jan 2006, Marcelo Matus wrote:
> The cast list that swig save refers to explicit cast, for example, if you
> have:
>  struct A {};
>  struct B : A {};
> swig save the relation or cast from B -> A, using a method like
>   void* BtoA(void *ptr) { return  (A*) (B *)(ptr);}

Oh ok, and more importantly it refers to explicit casts of pointers to=20
objects, and not to objects themselves, so it has nothing to do with=20
overloading casts ("operator" followed by a typename)

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - t=E9l:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montr=E9al QC Canada

On Tue, January 24, 2006 12:13 am, Marcelo Matus said:
>>The simplest way to do this would be to add a %import "mod2.i" to the
>>bottom of mod1.i.  Then the mod1 type table correctly exports the
>>connection between A and C.  The only downside is it exports the type D
>>too, making the module a little bit bigger.... but going back to a N log
>> N
>>importing makes this a small concern.  If it was, we would just need to
>>improve the detection that a type is not actually used anywhere, or add a
>>%removetype D code or something.
>>
>>
>>
> the problem is, of course, you are asking the users to re-write the
> interfaces in a smarter way
> to overcome the runtime library features.  the "mod" case is just a
> simple example where human
> intervention will be needed, and that is a very simple case.

I still argue that import is correct solution.  You are using a type in
mod1, (namely C) without telling SWIG anything about it.  In mod2, you are
using a few types (A and B) without telling SWIG anything about it.  I am
not really seeing the difference between the two.  For one case, we
require import and for the other we don't?  In theory, we could scrap
%import completly, and merge all the type information at run-time...

Actually with the change in swiginit.swg, I think you might be able to
remove the import from mod2.i... except of course you get a warning
mod2.i:3: Warning(401): Nothing known about base class 'B'. Ignored.
Why should we ignore class 'B' in mod2.i, when we don't ignore class C in
mod1.i?

The reason we have %import in the first place is so SWIG knows all the
type information about all the types used in the interface, and so that
multiple interfaces don't mess with the types differently.  It also allows
more to be done at SWIG generation time and less at run time loading.

I fail to see how adding one line to a bunch of interface files is a big
deal... you can do it with a find | xargs echo ' ' >> if there are a lot
of files, and if you have two mutually dependent modules I think each
should import the other.

If it is too much work, I think we should remove %import entirly.  I think
it should be both or none, why support one case of not telling SWIG enough
information one way, and another case of not telling SWIG enough
information another?

>
> Things can be a lot worse, for example,  take a look at PyICU, they have
> around
> 10 modules and multiple cross imports, a lot of them to be specific. The
> last swig version
> that worked with PyICU was 1.3.24. With the last changes in the runtime
> library PyICU is
> working again, and no change was needed in the PyICU interfaces. And the
> init time is  really
> neglectable.
>
> So, if you plan to play with the runtime library a little more, which I
> welcome a lot,
> at least we should establish a list of large "legacy" projects  that
> should keep running with no
> extra human intervention, and since PyICU is a nice "multi-cross-import"
> case, I propose it as the
> first in the list. You can also use it also as a benchmark case to see
> how fast the swig initialization
> runs.

I had a perl script that outputed C code with like 6000 classes A1, A2,
etc.  and I was using that to run tests... but if we could have a script
that would download and run some big projects, that would be good. 
Something like writing a shell script to wget big projects, ./configure,
make, make test or whatever.  Could also use expect too.

John

John Lenz wrote:

>On Tue, January 24, 2006 12:13 am, Marcelo Matus said:
>  
>
>>>The simplest way to do this would be to add a %import "mod2.i" to the
>>>bottom of mod1.i.  Then the mod1 type table correctly exports the
>>>connection between A and C.  The only downside is it exports the type D
>>>too, making the module a little bit bigger.... but going back to a N log
>>>N
>>>importing makes this a small concern.  If it was, we would just need to
>>>improve the detection that a type is not actually used anywhere, or add a
>>>%removetype D code or something.
>>>
>>>
>>>
>>>      
>>>
>>the problem is, of course, you are asking the users to re-write the
>>interfaces in a smarter way
>>to overcome the runtime library features.  the "mod" case is just a
>>simple example where human
>>intervention will be needed, and that is a very simple case.
>>    
>>
>
>I still argue that import is correct solution.  You are using a type in
>mod1, (namely C) without telling SWIG anything about it.  In mod2, you are
>using a few types (A and B) without telling SWIG anything about it.  I am
>not really seeing the difference between the two.  For one case, we
>require import and for the other we don't?  In theory, we could scrap
>%import completly, and merge all the type information at run-time...
>
>Actually with the change in swiginit.swg, I think you might be able to
>remove the import from mod2.i... except of course you get a warning
>mod2.i:3: Warning(401): Nothing known about base class 'B'. Ignored.
>Why should we ignore class 'B' in mod2.i, when we don't ignore class C in
>mod1.i?
>
>The reason we have %import in the first place is so SWIG knows all the
>type information about all the types used in the interface, and so that
>multiple interfaces don't mess with the types differently.  It also allows
>more to be done at SWIG generation time and less at run time loading.
>
>I fail to see how adding one line to a bunch of interface files is a big
>deal... you can do it with a find | xargs echo ' ' >> if there are a lot
>of files, and if you have two mutually dependent modules I think each
>should import the other.
>
>If it is too much work, I think we should remove %import entirly.  I think
>it should be both or none, why support one case of not telling SWIG enough
>information one way, and another case of not telling SWIG enough
>information another?
>
>  
>
sorry, what example are you looking at?, the one that was fixed, after 
adding the proper %import
directive, class forward declaration, etc, is the one in the test-suite:

       Example/test-suite/mod_a.i
       Example/test-suite/mod_b.i

Marcelo

>>Things can be a lot worse, for example,  take a look at PyICU, they have
>>around
>>10 modules and multiple cross imports, a lot of them to be specific. The
>>last swig version
>>that worked with PyICU was 1.3.24. With the last changes in the runtime
>>library PyICU is
>>working again, and no change was needed in the PyICU interfaces. And the
>>init time is  really
>>neglectable.
>>
>>So, if you plan to play with the runtime library a little more, which I
>>welcome a lot,
>>at least we should establish a list of large "legacy" projects  that
>>should keep running with no
>>extra human intervention, and since PyICU is a nice "multi-cross-import"
>>case, I propose it as the
>>first in the list. You can also use it also as a benchmark case to see
>>how fast the swig initialization
>>runs.
>>    
>>
>
>I had a perl script that outputed C code with like 6000 classes A1, A2,
>etc.  and I was using that to run tests... but if we could have a script
>that would download and run some big projects, that would be good. 
>Something like writing a shell script to wget big projects, ./configure,
>make, make test or whatever.  Could also use expect too.
>
>John
>
>  
>

John Lenz wrote:
> On Tue, January 24, 2006 12:13 am, Marcelo Matus said:
>>>The simplest way to do this would be to add a %import "mod2.i" to the
>>>bottom of mod1.i.  Then the mod1 type table correctly exports the
>>>connection between A and C.  The only downside is it exports the type D
>>>too, making the module a little bit bigger.... but going back to a N log
>>>N
>>>importing makes this a small concern.  If it was, we would just need to
>>>improve the detection that a type is not actually used anywhere, or add a
>>>%removetype D code or something.
>>>
>>>
>>>
>>the problem is, of course, you are asking the users to re-write the
>>interfaces in a smarter way
>>to overcome the runtime library features.  the "mod" case is just a
>>simple example where human
>>intervention will be needed, and that is a very simple case.
> 
> I still argue that import is correct solution.  You are using a type in
> mod1, (namely C) without telling SWIG anything about it.  In mod2, you are
> using a few types (A and B) without telling SWIG anything about it.  I am
> not really seeing the difference between the two.  For one case, we
> require import and for the other we don't?  In theory, we could scrap
> %import completly, and merge all the type information at run-time...
> 
> Actually with the change in swiginit.swg, I think you might be able to
> remove the import from mod2.i... except of course you get a warning
> mod2.i:3: Warning(401): Nothing known about base class 'B'. Ignored.
> Why should we ignore class 'B' in mod2.i, when we don't ignore class C in
> mod1.i?
> 
> The reason we have %import in the first place is so SWIG knows all the
> type information about all the types used in the interface, and so that
> multiple interfaces don't mess with the types differently.  It also allows
> more to be done at SWIG generation time and less at run time loading.
> 
> I fail to see how adding one line to a bunch of interface files is a big
> deal... you can do it with a find | xargs echo ' ' >> if there are a lot
> of files, and if you have two mutually dependent modules I think each
> should import the other.
> 
> If it is too much work, I think we should remove %import entirly.  I think
> it should be both or none, why support one case of not telling SWIG enough
> information one way, and another case of not telling SWIG enough
> information another?
> 
>>Things can be a lot worse, for example,  take a look at PyICU, they have
>>around
>>10 modules and multiple cross imports, a lot of them to be specific. The
>>last swig version
>>that worked with PyICU was 1.3.24. With the last changes in the runtime
>>library PyICU is
>>working again, and no change was needed in the PyICU interfaces. And the
>>init time is  really
>>neglectable.
>>
>>So, if you plan to play with the runtime library a little more, which I
>>welcome a lot,
>>at least we should establish a list of large "legacy" projects  that
>>should keep running with no
>>extra human intervention, and since PyICU is a nice "multi-cross-import"
>>case, I propose it as the
>>first in the list. You can also use it also as a benchmark case to see
>>how fast the swig initialization
>>runs.
> 
> I had a perl script that outputed C code with like 6000 classes A1, A2,
> etc.  and I was using that to run tests... but if we could have a script
> that would download and run some big projects, that would be good. 
> Something like writing a shell script to wget big projects, ./configure,
> make, make test or whatever.  Could also use expect too.
> 

This would be great if someone has the bandwidth to do this. Testing is
really important and I don't think it is unusual for a lot of time to be
spent on testing compared to development in a large project like SWIG.

William

On Tue, January 24, 2006 11:23 pm, Marcelo Matus said:

> sorry, what example are you looking at?, the one that was fixed, after
> adding the proper %import
> directive, class forward declaration, etc, is the one in the test-suite:
>
>        Example/test-suite/mod_a.i
>        Example/test-suite/mod_b.i
>

The one posted by Robin Dunn as an attachment to an email in this thread. 
Although looking at the code in the test suite, where I say mod1 it is the
same as mod_a, and mod2 is mod_b.

John

John Lenz wrote:

>On Tue, January 24, 2006 11:23 pm, Marcelo Matus said:
>
>  
>
>>sorry, what example are you looking at?, the one that was fixed, after
>>adding the proper %import
>>directive, class forward declaration, etc, is the one in the test-suite:
>>
>>       Example/test-suite/mod_a.i
>>       Example/test-suite/mod_b.i
>>
>>    
>>
>
>The one posted by Robin Dunn as an attachment to an email in this thread. 
>Although looking at the code in the test suite, where I say mod1 it is the
>same as mod_a, and mod2 is mod_b.
>
>John
>
>  
>
oh, well, as you see in the example in the test suite, even after adding 
the %import directive, and
the class forward declaration for C, as should be the correct way, swig 
had problems.

The issue is that when C is declared using a class forward: internally 
swig rcognizes C as a "weak type"
in mod_a, but swig adds C to the runtime type as a "full" type to the 
runtime type system.

Then in mod_b, where C is finally defined, swig recogines that the type 
is already defined and
the problem occurred.

So, analyzing the case a little more, we can see that there are good and 
bad news.
The bad news is that it seems there is no way to work around the problem 
with just calling %import,
since we would need something like circular-cross importing, ie, mod_a 
should import mod_b and
mod_b should import mod_a. The good news is that the added patch, which 
requires to search in the
type cast list to avoid multiple entries, only is activated in this 
corner case.

i.e, for "normal" modules, where there is no circular type referencing, 
or mixed forward class declarations,
there should be no performance penalty, and the linear search only 
occurs when otherwise you would end
with a bad type systems, so, it seems a minimal cost to me.

It would be interesting if you can test with your example of 6000 types 
and check if there is
a change in the runtime performance with the last modification. Also, I 
guess you should add that
test to the test-suite, so, we could monitor if any other change in the 
affects or breaks
the runtime library.


Marcelo

On Wed, January 25, 2006 9:33 pm, Marcelo Matus said:

> i.e, for "normal" modules, where there is no circular type referencing,
> or mixed forward class declarations,
> there should be no performance penalty, and the linear search only
> occurs when otherwise you would end
> with a bad type systems, so, it seems a minimal cost to me.

Ok, I'll take a closer look.  Sorry about the delay, my computer died on me.

>
> It would be interesting if you can test with your example of 6000 types
> and check if there is
> a change in the runtime performance with the last modification. Also, I
> guess you should add that
> test to the test-suite, so, we could monitor if any other change in the
> affects or breaks
> the runtime library.

Actually, the code (and the results) are still on my web page at
http://www.cs.wisc.edu/~lenz/swig.html

check out http://www.cs.wisc.edu/~lenz/swig/hugemod.txt

I'm still trying to get my development environment back, so if you want to
commit that feel free...

John

John Lenz wrote:

>On Wed, January 25, 2006 9:33 pm, Marcelo Matus said:
>
>  
>
>>i.e, for "normal" modules, where there is no circular type referencing,
>>or mixed forward class declarations,
>>there should be no performance penalty, and the linear search only
>>occurs when otherwise you would end
>>with a bad type systems, so, it seems a minimal cost to me.
>>    
>>
>
>Ok, I'll take a closer look.  Sorry about the delay, my computer died on me.
>
>  
>
>>It would be interesting if you can test with your example of 6000 types
>>and check if there is
>>a change in the runtime performance with the last modification. Also, I
>>guess you should add that
>>test to the test-suite, so, we could monitor if any other change in the
>>affects or breaks
>>the runtime library.
>>    
>>
>
>Actually, the code (and the results) are still on my web page at
>http://www.cs.wisc.edu/~lenz/swig.html
>
>check out http://www.cs.wisc.edu/~lenz/swig/hugemod.txt
>
>I'm still trying to get my development environment back, so if you want to
>commit that feel free...
>
>John
>
>  
>
Ok, here are some numbers

using 1.3.27:

$ time python hugemod_runme.py
real    0m10.648s
user    0m10.374s
sys     0m0.233s

and using 1.3.27 with -modern:

time python hugemod_runme.py
real    0m9.138s
user    0m8.740s
sys     0m0.216s


and using 1.3.28:

$ time python hugemod_runme.py
real    0m8.491s
user    0m8.247s
sys     0m0.209s

and using 1.3.28 with -O option:

$ time python hugemod_runme.py
real    0m7.190s
user    0m6.930s
sys     0m0.208s

Marcelo

John Lenz wrote:

>On Wed, January 25, 2006 9:33 pm, Marcelo Matus said:
>
>  
>
>>i.e, for "normal" modules, where there is no circular type referencing,
>>or mixed forward class declarations,
>>there should be no performance penalty, and the linear search only
>>occurs when otherwise you would end
>>with a bad type systems, so, it seems a minimal cost to me.
>>    
>>
>
>Ok, I'll take a closer look.  Sorry about the delay, my computer died on me.
>
>  
>
>>It would be interesting if you can test with your example of 6000 types
>>and check if there is
>>a change in the runtime performance with the last modification. Also, I
>>guess you should add that
>>test to the test-suite, so, we could monitor if any other change in the
>>affects or breaks
>>the runtime library.
>>    
>>
>
>Actually, the code (and the results) are still on my web page at
>http://www.cs.wisc.edu/~lenz/swig.html
>
>check out http://www.cs.wisc.edu/~lenz/swig/hugemod.txt
>
>I'm still trying to get my development environment back, so if you want to
>commit that feel free...
>
>John
>
>
>
>-------------------------------------------------------
>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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Swig-devel mailing list
>Swig-devel@...
>https://lists.sourceforge.net/lists/listinfo/swig-devel
>  
>
More numbers, just loading the modules, ie:

import hugemod_a
import hugemod_b

using 1.3.27 (-modern):
time python load.py
real    0m6.715s
user    0m6.519s
sys     0m0.167s

using 1.3.28 (-O):
time python load.py
real    0m5.837s
user    0m5.465s
sys     0m0.155s

John Lenz wrote:

>On Wed, January 25, 2006 9:33 pm, Marcelo Matus said:
>
>  
>
>>i.e, for "normal" modules, where there is no circular type referencing,
>>or mixed forward class declarations,
>>there should be no performance penalty, and the linear search only
>>occurs when otherwise you would end
>>with a bad type systems, so, it seems a minimal cost to me.
>>    
>>
>
>Ok, I'll take a closer look.  Sorry about the delay, my computer died on me.
>
>  
>
>>It would be interesting if you can test with your example of 6000 types
>>and check if there is
>>a change in the runtime performance with the last modification. Also, I
>>guess you should add that
>>test to the test-suite, so, we could monitor if any other change in the
>>affects or breaks
>>the runtime library.
>>    
>>
>
>Actually, the code (and the results) are still on my web page at
>http://www.cs.wisc.edu/~lenz/swig.html
>
>check out http://www.cs.wisc.edu/~lenz/swig/hugemod.txt
>
>I'm still trying to get my development environment back, so if you want to
>commit that feel free...
>
>John
>
>
>
>-------------------------------------------------------
>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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Swig-devel mailing list
>Swig-devel@...
>https://lists.sourceforge.net/lists/listinfo/swig-devel
>  
>
Ok, here is the difference, loading just the c-modules, ie:

import _hugemod_a
import _hugemod_b

using 1.3.27:

time python load.py
real    0m0.433s
user    0m0.386s
sys     0m0.039s


and using 1.3.28:

time python load.py
real    0m0.437s
user    0m0.395s
sys     0m0.035s

ie, here 1.3.28 is 1% slower, and that should be the cost of the extra 
checking
added in the runtime library. And even when that is insignificant, in 
practical
cases you don't even see it, since when you load full proxy python modules,
and use them, 1.3.28 is always faster than 1.3.27. In this particular case,
you can get speeds up to  20% faster, and that includes the python
script time,  ie, the time to interpret and run hugemod_runme.py.
In other words, to see the 20% speed up, 1.3.28 must be much faster
than that.

Marcelo