Hi Nicolai, > On Jan 28, 2016, at 1:27 PM, Nicolai Hess <[email protected]> wrote: > > 2016-01-28 22:12 GMT+01:00 Nicolas Cellier > <[email protected]>: >> 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 <[email protected]>: >>> 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 <[email protected]> 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 > > Is it common to use #assert: outside of unit tests? I always saw this as part > of sunit and wondering why one would want to disable it. > Sure, there are other language which uses some assert-like construct for > runtime checks. But I would have thought smalltalk just does not > use it like that or we would have another one, that is not used for sunit > tests.
My VMMaker.oscog VM source is full of asserts and it is a key debugging tool. When C source is generated assert becomes a macro which allows asserts to be eliminated from the production VM. I also use "eassert" (expensive assert, which is only evaluated when a flag is set) and deny: because it is very nicely readable. I picked up this style from Peter Deutch's HPS VM, the VW VM, written in C. I was introduced to preconditions and post conditions at college and asserts are very similar, and can subsume that style. But I am open to a compiler switch to turn them off. I'll answer why in a reply to the next message in thread. > nicolai _,,,^..^,,,_ (phone)
