<headius[m]>
another justification for splitting blocks lazily into different forms: Proc#call does its own arg processing before passing to the block, which then re-processes them again
<headius[m]>
worth looking into whether both are really needed but the protocol for these things is so involved
<headius[m]>
the indy logic for binding Proc#call can reduce that processing somewhat since it has input args and knows target arity, but ideally it wouldn't have to
ur5us_ has quit [Ping timeout: 260 seconds]
ur5us_ has joined #jruby
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
nirvdrum has quit [Remote host closed the connection]
ur5us_ has quit [Read error: Connection reset by peer]
<headius[m]>
enebo: I put the block improvements into a PR and added some benchmark numbers
<headius[m]>
I also included numbers for when it isn't an inlined indy yield...the lion's share of these optimizations will improve all leaf blocks that can eliminate the frame
<headius[m]>
I really would like to see some big impact from this 🙂 There's a lot of leaf blocks in Ruby
<enebo[m]>
headius: I will just merge once travis re-oks it
<enebo[m]>
I am going to try a graphql bench I was just running
<headius[m]>
there's more to be done here too...we're still checking both block type and eval type on every entry
<enebo[m]>
we are slower than MRI without indy on by like 40%
<enebo[m]>
they do a nutty amount of simple nested closures
<headius[m]>
best solution there would be to move those operations into IR and emit different code for lambda vs normal, module_eval versus no eval
<headius[m]>
oh I just realized something
<headius[m]>
nested closures shouldn't need to push a frame either
<enebo[m]>
as we were saying if that really does not change once set we can eliminate evalType pretty easily
<headius[m]>
so like 1.times { 1.times { } }
<headius[m]>
the containing method neds to make a frame available for both blocks, but the outer block shouldn't need to push it since it doesn't use it
<headius[m]>
the inner block can be created just based on the outer block's binding
<headius[m]>
we have lots of opportunity here
<headius[m]>
so potentially if we have nested blocks that don't access frame we could eliminate all frame pushes except the one at the method level
<headius[m]>
wow how did that finish travis so fast
<enebo[m]>
I was noticing earlier in the week your first build seemed way faster than our others
<enebo[m]>
I was not sure if you got "lucky" somehow on travis instance or ?
<headius[m]>
yeah I was noticing that too
<headius[m]>
and MRI finishing in 12 minutes is really unusually fast
<enebo[m]>
I guess digging more into whether anything in IRScope.needsFrame() is conservative would be a good next step too
<headius[m]>
it's possible travis bumped up speed or something so I don't know
<enebo[m]>
going to test on graphql but are all builds faster?
<enebo[m]>
it is like 30 minutes faster from what I saw
<enebo[m]>
so something with travis having better or worse vms? Or maybe just some networking influence
<headius[m]>
172?
<enebo[m]>
that job is 172 minutes
<enebo[m]>
170-190 minutes is about what I expect
<enebo[m]>
ignore me looking back 190ish is more the normal time
<headius[m]>
yeah it does seem faster
<headius[m]>
bit by bit
<headius[m]>
@rd
<headius[m]>
rdubya: hey returning to that issue you mentioned
<headius[m]>
in JRuby I know that our method invalidation impacts startup time to some extent, both for simple commands and for larger apps
<headius[m]>
Especially if you are making modifications at a high level like Kernel or Object... we invalidate all classes below that so e.g. Kernel changes have to walk every class in the system
<headius[m]>
invalidateClassHierarchy in RubyModule I think
<headius[m]>
there's gotta be a better way but I have not dug into it for a while
<rdubya[m]>
interesting
<headius[m]>
this also flips the bit on a bunch of invokedynamic SwitchPoint which has a surprisingly high cost
sagax has quit [Ping timeout: 265 seconds]
Gacha has joined #jruby
sagax has joined #jruby
Gacha has quit [Read error: Connection reset by peer]