<div dir="ltr">The EXTENDED_ARG is included in the multibyte ops, I treat it just like any other operator. Here's a snippet of my hacked-dis.dis output, which made it clear to me that I could just count them as an "operator with word operand."<div><br></div><div>Line 3000: x = x if x or not x and x is None else x</div><div><div>0001dc83 7c 00 00 LOAD_FAST x</div><div>0001dc86 91 01 00 EXTENDED_ARG 1</div><div>0001dc89 70 9f dc JUMP_IF_TRUE_OR_POP L1dc9f</div><div>0001dc8c 7c 00 00 LOAD_FAST x</div><div>0001dc8f 0c UNARY_NOT</div><div>0001dc90 91 01 00 EXTENDED_ARG 1</div><div>0001dc93 6f 9f dc JUMP_IF_FALSE_OR_POPL1dc9f</div><div>0001dc96 7c 00 00 LOAD_FAST x</div><div>0001dc99 74 01 00 LOAD_GLOBAL None</div><div>0001dc9c 6b 08 00 COMPARE_OP 'is'</div><div> L1dc9f:</div><div>0001dc9f 91 01 00 EXTENDED_ARG 1</div><div>0001dca2 72 ab dc POP_JUMP_IF_FALSE L1dcab</div><div>0001dca5 7c 00 00 LOAD_FAST x</div><div>0001dca8 6e 03 00 JUMP_FORWARD L1dcae (+3)</div><div> L1dcab:</div><div>0001dcab 7c 00 00 LOAD_FAST x</div><div> L1dcae:</div><div>0001dcae 7d 00 00 STORE_FAST x</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 2:23 PM, Victor Stinner <span dir="ltr"><<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2016-04-13 23:02 GMT+02:00 Eric Fahlgren <<a href="mailto:ericfahlgren@gmail.com">ericfahlgren@gmail.com</a>>:<br>
> Percentage of 1-byte args = 96.80%<br>
<br>
</span>Yeah, I expected such high ratio. Good news that you confirm it.<br>
<span class=""><br>
<br>
> Non-argument ops = 53,719<br>
> One-byte args = 368,787<br>
> Multi-byte args = 12,191<br>
<br>
</span>Again, only a very few arguments take multiple bytes. Good, the<br>
bytecode will be smaller.<br>
<br>
IMHO it's more a nice side effect than a real goal. The runtime<br>
performance matters more than the size of the bytecode, it's not like<br>
a bytecode take 4 MB. It's probably closer to 1 KB and so can probably<br>
benefit of the fatest CPU caches.<br>
<span class=""><br>
<br>
> Just for the record, here's my arithmetic:<br>
> byteCodeSize = 1*nonArgumentOps + 3*oneByteArgs + 3*multiByteArgs<br>
> wordCodeSize = 2*nonArgumentOps + 2*oneByteArgs + 4*multiByteArgs<br>
<br>
</span>If multiByteArgs means any size > 1 byte, the wordCodeSize formula is wrong:<br>
<br>
- no parameter: 2 bytes<br>
- 8-bit parameter: 2 bytes<br>
- 16-bit parameter: 4 bytes<br>
- 24-bit parameter: 6 bytes<br>
- 32-bit parameter: 8 bytes<br>
<br>
But you wrote that you didn't see EXTEND_ARG, so I guess that<br>
multibyte means 16-bit in your case, and so your formula is correct.<br>
<br>
Hopefully, I don't expect 32-bit parameters in the wild, only 24-bit<br>
parameter for function with annotation.<br>
<span class=""><br>
<br>
> (It is interesting to note that I have never encountered an EXTENDED_ARG operator in the wild, only in my own synthetic examples.)<br>
<br>
</span>As I wrote, EXTENDED_ARG can be seen when MAKE_FUNCTION is used with<br>
annotations.<br>
<span class="HOEnZb"><font color="#888888"><br>
Victor<br>
</font></span></blockquote></div><br></div>