I wonder if an override of assert/assert: with ^self in production will
make a noticeable performance drop once inlining JIT is ready.
Of course eliminating the send with compiler hack eliminates some work for
inliner, but it sounds like manual optimization duplicating automatic
optimizer work.

2016-01-28 21:50 GMT+01:00 stepharo <steph...@free.fr>:

> Marcus
>
> I do not really like that we get per class behavior.
> I would prefer to have a
>
> Compiler recompileAllForProductionAndNoAssert
> or at the level of the package.
>
> Stef
>
> Hello,
>
> Yes, we should experiment with that.
>
> A compiler option is very easy to add… and easy to understand. And trivial
> to do.
>
> 1) step one:
>
> add the following line at the start of OCASTTranslator>>emitMessageNode:
>
> self compilationContext optionDisableAssert ifTrue: [
> aMessageNode selector == #assert: ifTrue: [ ^methodBuilder pushReceiver ]
>  ].
>
> 2) step 2. There is no step. 2 ;-). Maybe a better version would use
> plugin… changing the code generator like that
> is a bit a hack. But it works.
>
> You can now turn off all sends to #assert: by enabling the
> #optionDisableAssert compiler option.
> e.g. class wide by setting on the class side in
>
> compiler
> ^super compiler options: #(+ optionDisableAssert).
>
>
> More magic is, of course, always possible later… I have some ideas.
>
> Marcus
>
>
> On 28 Jan 2016, at 13:54, Aliaksei Syrel < <alex.sy...@gmail.com>
> alex.sy...@gmail.com> wrote:
>
> Hi
>
> Assertions play an important role in design by contract. It is great to
> have assertions in Pharo out of box (Object>>#assert:). However in projects
> with many post- and precondition as also class invariants heavy usage of
> assertions decreases performance...
>
> Would it be possible to have a compiler setting (in setting browser) to
> enable/disable assertions and not compile them to bytecode? Compiler should
> ignore the whole assertion statement with removed condition. For example:
>
>> self assert: self hugeInvariant.
>
> with disabled assertion hugeInvariant must not be sent.
>
> Thanks,
> Alex
>
>
>
>

Reply via email to