Andrew,

you are correct (as far as I've gotten your mail, see below), but...

Besides that I've posted a changeset
	TIPlugin-cleanup-sr.1.cs.gz
in mail subjected
	[ENH] TestInterpreterPlugin-cleanup-sr
recently (triggered by this discussion), which simplifies the >>sqAssert:
and therefore...

"Andrew C. Greenberg" wrote:
> 
> On Wednesday, January 2, 2002, at 02:11  AM, John M McIntosh wrote:
> 
> > LargeIntegersPlugin>>assert: aBool
> >       self
> >           debugCode:
> >               [aBool ifFalse:
> >                       [self msg: 'Assertion failed!'.
> >                       self cCode: 'exit(1)'
> >                       inSmalltalk:
> >                       [interpreterProxy primitiveFail.
> >                       self halt]].
> >                       ^ true]
> 
> Well, even as a compromise, this ignores that the code, as written, is
> broken!  I suggest eliminating it altogether as used here.  Because of
> the
> 
>         #self cCode:inSmalltalk
> 
> message, this method will not be inlined to the caller, even though the
> #debugCode inlines the generated code of #assert: to blank!  This is
> what appears to be happening in the generated code for
> LargeIntegerPlugin.
> 
> Thus, the generated code for the production version contains calls like:
> 
>         assert(limit < lenFrom);
> 
> which are evaluated for an empty procedure,  I don't know how many
> optimizing compilers are smart enough to pick this one up, but with less
> than careful optimiztion, this means that all your assertion expressions
> are evaluated.

... avoids this problem:

- the current production LargeIntegersPlugin>>assert: is used very rarely;
- I've thought that compilers are able to optimize this call away (in
production code generated by default), since then
  - C assert() is an empty function,
  - there is no function call in the arguments of the generated C assert()
calls,
  - there is no side effect while evaluating the arguments of the generated
C assert() calls;
- in the worst case (stupid compiler) these very few to be evaluated boolean
expressions should have negligable impact on performance.

Resumee: There is a better solution, but there is no reason to make panic:
the LargeIntegersPlugin is fast with or without these assert()'s!


Greetings,

Stephan

> 
> This is particularly egregious for LargeIntegersPlugin, since that code
> tends to live inside many inner loops for computation-intensive work.
> The microseconds wasted for such computations -- which are unnecessary
> if this were done differently -- add up.
> 
> Thus, in addition to the decidedly annoying problems with some important
> platform development systems and the like, this structure is also highly
> inefficient, because

PS: Here your mail has been truncated for me...

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3