[HN Gopher] Diggin' and Fetchin' with TruffleRuby
       ___________________________________________________________________
        
       Diggin' and Fetchin' with TruffleRuby
        
       Author : chrisseaton
       Score  : 52 points
       Date   : 2021-08-24 21:58 UTC (1 days ago)
        
 (HTM) web link (shopify.engineering)
 (TXT) w3m dump (shopify.engineering)
        
       | pqdbr wrote:
       | I love #fetch and I feel it makes my code safer. I use it all the
       | time.
       | 
       | { success: true }[:sucess] is nil (notice that you got a falsy
       | value due to a typo in `success`), while { success: true
       | }.fetch(:sucess) will raise and warn you about your mistake, and
       | Ruby is nice enough to throw a `Did you mean? :success` for you
       | there.
       | 
       | One small tip about fetch: remember that every method in Ruby
       | always fully evaluates all its arguments.
       | 
       | So, if you use it like { data: [ ] }.fetch(:data,
       | get_data_via_very_expensive_method_call), the method
       | `get_data_via_very_expensive_method_call` will always be called,
       | because it's an argument and it will be evaluated BEFORE it's
       | passed to fetch.
       | 
       | That's why one should prefer using the block form in cases like
       | this:
       | 
       | { data: [ ] }.fetch(:data) {
       | get_data_via_very_expensive_method_call } will only call
       | `get_data_via_very_expensive_method_call` if the Hash doesn't
       | have the :data key.
        
       | phibz wrote:
       | I wonder if indxs.unshift would have been faster than i < size,
       | indxs[i]
        
       | ljm wrote:
       | I imagine the premise of this post is basically to just kick off
       | an exploration into TruffleRuby, which is cool! And an
       | interesting read re: the benchmarking and performance of the
       | implementation.
       | 
       | A shame that refinements don't really get much love, because the
       | third option (in between monkey patching and extending the core
       | library), is to use one of those.                   module
       | DigWithFallback           refine Hash do             def
       | dig_fetch(*keys)               # ... impl             end
       | end         end              class SomeService           using
       | DigWithFallback                def call(params)
       | params.dig_fetch(:some, :key) { IdentityObject.new }
       | end         end
        
         | byroot wrote:
         | > A shame that refinements don't really get much love
         | 
         | Their performance is quite awful on MRI. Any method that was
         | refined is tagged as such, which incur a 40% performance hit
         | (for empty methods)[0]. That alone tend to disqualify them for
         | many use cases.
         | 
         | Then, it might get fixed, but whenever you call `using` all the
         | heap is scanned and all methods caches flushed [1], which is a
         | massive perf hit if it happens often.
         | 
         | TruffleRuby however runs them fast, but since most code out
         | there target MRI, they're not really a good idea except for
         | fringe use cases.
         | 
         | [0]
         | https://gist.github.com/casperisfine/1c46f05cccfa945cd156f44...
         | [1] https://github.com/ruby/ruby/pull/4323
        
           | eregon wrote:
           | Interesting, I did not know that just calling the original
           | method, even when the refinement method is not used occurs
           | such a cost on CRuby. Seems worth reporting if not already
           | done. No such thing on TruffleRuby though, the only peak
           | performance cost would be for megamorphic calls (rare, even
           | more so in combination with refinements).
        
             | byroot wrote:
             | > Seems worth reporting if not already done.
             | 
             | I assumed it is expected overhead.
        
         | aardvark179 wrote:
         | I think refinements are better than monkey patching, I mean
         | they won't cause unexpected behaviour elsewhere, but on the
         | other hand they add a whole new layer of complexity to
         | understanding a code base.
        
       ___________________________________________________________________
       (page generated 2021-08-25 23:01 UTC)