Looking at RAMification, there is a huge amount of bytecode size used by just a few functions: Compiled #BQ3sh9 into bytecode 6665586 instructions in 41.487042 ms (json-stringify-inspector) Compiled #CgZEBF into bytecode 11333483 instructions in 142.271417 ms (FlightPlanner) Compiled #A6N0Pp into bytecode 10567153 instructions in 59.131208 ms. (mandreel) Compiled #CcfzTC into bytecode 602665 instructions in 11.553625 ms. (pdfjs) Three of these four functions are made almost exclusively of the sequences of put_by_id following a new_object, e.g.: [11292155] **new_object dst:loc9, inlineCapacity:5 [11292169] **put_by_id base:loc9, property:1, value:String (atomic),8Bit:(1),length:(5): ZUMOV, StructureID: 5044(const330505), flags:IsDirect [11292191] **put_by_id base:loc9, property:2, value:String (atomic),8Bit:(1),length:(12): Intersection, StructureID: 5044(const39646), flags:IsDirect [11292213] **put_by_id base:loc9, property:3, value:String (atomic),8Bit:(1),length:(18): ZUMOV Intersection, StructureID: 5044(const330506), flags:IsDirect With a highly variable number of put_by_id (from 2 to more than 300). So I'd like to offer a new variadic opcode new_object_with_properties, that would correspond exactly to this kind of sequence. It should both massively help bytecode size, and improve interpretation time, both by reducing the overhead of instruction dispatch, and by allowing to skip directly to the right structure instead of doing a ton of costly transitions. The main challenge is that we currently don't have truly variadic opcodes, instead we are using a hack where we put the arguments in order on the stack, and give the opcode their number and the offset of the first one. This would not help here, since it would require two mov per put_by_id. So a first step here would be adding support for true variadic opcodes.
<rdar://problem/90575042>