Hi Per, Yes, you are of cause right: the performance penalty is also due to the use of macro-case instead of build-in case – and in fact it is the largest part using bigloo.
Out of curiosity I did a small test with bigloo, looping 10 Mio times over a case expression (that cannot be optimized away by the compiler). The runtime increase with macro case and member is about 100%. Only about 25% of the runtime increase is due to the use of member instead of memv. For most applications these performance differences are probably not relevant. Best regards Bent 2017-01-21 17:54 GMT+01:00 Per Bothner <[email protected]>: > On Tue, Jan 17, 2017 at 8:27 PM, Bent Phillipsen < > [email protected]> wrote: > >> This has the consequence that stings cannot be used as key and clause in >> case expressions in a well defined way (or at least portable way). You can >> however easily define a macro that *also* can use strings. You can write >> your own; but simply taking the case macro defined in R5RS (p.43) ensures >> that all corner cases are handled correctly. You then just need to replace >> 'memv' with 'member' (this has the effect of testing equivalence with >> equal? >> instead of eqv?). You probably want to change the name of the macro also, >> for instance to case-member, to avoid shadowing the original case >> expression. You will get something like the following, which should work >> and >> which I think is portable. (There is of cause a (mostly insignificant) >> performance penalty in testing with equal? instead of eqv?): >> > > In Kawa 'case' is optimized, so the performance penalty of re-implementing > case "by hand" would be more significant. > -- > --Per Bothner > [email protected] http://per.bothner.com/ >
