Bug #13708
closed
catastrophic slow compilation of defined-defined sequence has no chance to ^C
Description
Attached script, which is only 139 bytes long, generates iseq of 352,321,600 bytes on my 64bit machine. That compilation takes long time.
Execution itself is almost instant, though.
Files
Related issues
Updated by jeremyevans0 (Jeremy Evans) about 2 months ago
- Related to Bug #17649: `defined?` invokes method once for each syntactic element around it added
Updated by jeremyevans (Jeremy Evans) 18 days ago
- Status changed from Open to Closed
Applied in changeset git|7b3c5ab8a5825a2b960e639d257f0c8a69c4186c.
Make defined? cache the results of method calls
Previously, defined? could result in many more method calls than
the code it was checking. defined? a.b.c.d.e.f generated 15 calls,
with a called 5 times, b called 4 times, etc.. This was due to
the fact that defined works in a recursive manner, but it previously
did not cache results. So for defined? a.b.c.d.e.f, the logic was
similar to
return nil unless defined? a
return nil unless defined? a.b
return nil unless defined? a.b.c
return nil unless defined? a.b.c.d
return nil unless defined? a.b.c.d.e
return nil unless defined? a.b.c.d.e.f
"method"
With this change, the logic is similar to the following, without
the creation of a local variable:
return nil unless defined? a
_ = a
return nil unless defined? _.b
_ = _.b
return nil unless defined? _.c
_ = _.c
return nil unless defined? _.d
_ = _.d
return nil unless defined? _.e
_ = _.e
return nil unless defined? _.f
"method"
In addition to eliminating redundant method calls for defined
statements, this greatly simplifies the instruction sequences by
eliminating duplication. Previously:
0000 putnil ( 1)[Li] 0001 putself 0002 defined func, :a, false 0006 branchunless 73 0008 putself 0009 opt_send_without_block <calldata!mid:a, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0011 defined method, :b, false 0015 branchunless 73 0017 putself 0018 opt_send_without_block <calldata!mid:a, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0020 opt_send_without_block <calldata!mid:b, argc:0, ARGS_SIMPLE> 0022 defined method, :c, false 0026 branchunless 73 0028 putself 0029 opt_send_without_block <calldata!mid:a, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0031 opt_send_without_block <calldata!mid:b, argc:0, ARGS_SIMPLE> 0033 opt_send_without_block <calldata!mid:c, argc:0, ARGS_SIMPLE> 0035 defined method, :d, false 0039 branchunless 73 0041 putself 0042 opt_send_without_block <calldata!mid:a, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0044 opt_send_without_block <calldata!mid:b, argc:0, ARGS_SIMPLE> 0046 opt_send_without_block <calldata!mid:c, argc:0, ARGS_SIMPLE> 0048 opt_send_without_block <calldata!mid:d, argc:0, ARGS_SIMPLE> 0050 defined method, :e, false 0054 branchunless 73 0056 putself 0057 opt_send_without_block <calldata!mid:a, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0059 opt_send_without_block <calldata!mid:b, argc:0, ARGS_SIMPLE> 0061 opt_send_without_block <calldata!mid:c, argc:0, ARGS_SIMPLE> 0063 opt_send_without_block <calldata!mid:d, argc:0, ARGS_SIMPLE> 0065 opt_send_without_block <calldata!mid:e, argc:0, ARGS_SIMPLE> 0067 defined method, :f, true 0071 swap 0072 pop 0073 leave
After change:
0000 putnil ( 1)[Li] 0001 putself 0002 dup 0003 defined func, :a, false 0007 branchunless 52 0009 opt_send_without_block <calldata!mid:a, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0011 dup 0012 defined method, :b, false 0016 branchunless 52 0018 opt_send_without_block <calldata!mid:b, argc:0, ARGS_SIMPLE> 0020 dup 0021 defined method, :c, false 0025 branchunless 52 0027 opt_send_without_block <calldata!mid:c, argc:0, ARGS_SIMPLE> 0029 dup 0030 defined method, :d, false 0034 branchunless 52 0036 opt_send_without_block <calldata!mid:d, argc:0, ARGS_SIMPLE> 0038 dup 0039 defined method, :e, false 0043 branchunless 52 0045 opt_send_without_block <calldata!mid:e, argc:0, ARGS_SIMPLE> 0047 defined method, :f, true 0051 swap 0052 pop 0053 leave
This fixes issues where for pathological small examples, Ruby would generate
huge instruction sequences.
Unfortunately, implementing this support is kind of a hack. This adds another
parameter to compile_call for whether we should assume the receiver is already
present on the stack, and has defined? set that parameter for the specific
case where it is compiling a method call where the receiver is also a method
call.
defined_expr0 also takes an additional parameter for whether it should leave
the results of the method call on the stack. If that argument is true, in
the case where the method isn't defined, we jump to the pop before the leave,
so the extra result is not left on the stack. This requires space for an
additional label, so lfinish now needs to be able to hold 3 labels.