<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi Levente.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">reorder the clauses based on the frequency of the positive matches</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">I think we should estimate the frequency of the "search term" not the positive matches. I think it is more likely that one checks for #> or #+ rather than 'true'.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Anyway, the false-case should be as fast as possible because it is the most common one given the overall value range of literals.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Marcel</span></div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 24.07.2019 13:51:27 schrieb Levente Uzonyi <leves@caesar.elte.hu>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Marcel,<br><br>On Wed, 24 Jul 2019, commits@source.squeak.org wrote:<br><br>> Marcel Taeumel uploaded a new version of Compiler to project The Trunk:<br>> http://source.squeak.org/trunk/Compiler-mt.405.mcz<br>><br>> ==================== Summary ====================<br>><br>> Name: Compiler-mt.405<br>> Author: mt<br>> Time: 24 July 2019, 11:17:04.167109 am<br>> UUID: 7354b36e-2509-4f23-b110-1b9cfe0310d2<br>> Ancestors: Compiler-mt.404<br>><br>> Adds message to avoid costly byte-code scanning for has-literal checks.<br>><br>> Note that ((... or: [...]) or: [...] ...) is a little bit faster to evaluate to false than (... or: [ ... or: [ ... ] ] ). I would suspect not but deeply nested blocks seem to have an interesting effect here.<br><br>I don't think there's any real difference between the two's performance.<br>If you have a look at the generated byte codes, you'll find that the <br>Compiler has inlined the blocks in both cases.<br>So, I preferer the latter version, because of better legibility.<br><br>There are at least three possibilities to speed up the method:<br>- reorder the clauses based on the frequency of the positive matches<br>- use the JIT's capability of generating better machine code when a <br>variable compared with a constant is the receiver of a "boolean message"<br>- use the JIT's capability of generating better machine code when <br>the returned value is a known boolean<br><br>Based on those, the following implementation ought to be faster:<br><br>   aLiteral == true ifTrue: [ ^true ].<br>   aLiteral == false ifTrue: [ ^true ].<br>  aLiteral == nil ifTrue: [ ^true ].<br>    (aLiteral isInteger and: [ aLiteral between: -32768 and: 32767 ]) ifTrue: [ ^true ].<br>  (aLiteral isCharacter and: [ aLiteral asInteger <= 65535="" ])="" iftrue:="" [="" ^true=""><!--=--><br>     (aLiteral isSymbol and: [ Smalltalk specialSelectors includes: aLiteral ]) ifTrue: [ ^true ].<br>         ^false<br><br>Levente<br><br>><br>> =============== Diff against Compiler-mt.404 ===============<br>><br>> Item was added:<br>> + ----- Method: BytecodeEncoder class>>canBeSpecialLiteral: (in category 'testing') -----<br>> + canBeSpecialLiteral: aLiteral<br>> +    "This check can be used to prevent unnecessary use of #scanBlockOrNilForLiteral:. For performance, this method summarizes specializations from all known bytecode encoders. It is not meant to be refined per encoder."<br>> + <br>> +      ^ ((((((aLiteral isSymbol and: [Smalltalk specialSelectors includes: aLiteral])<br>> +                 or: [aLiteral isInteger and: [aLiteral between: -32768 and: 32767]])<br>> +            or: [aLiteral isCharacter and: [aLiteral asInteger <=><!--=--><br>> +              or: [aLiteral == true])<br>> +                 or: [aLiteral == false])<br>> +                or: [aLiteral == nil])!<br><br></div></blockquote></div>