taking issue with Hash#fetch with argument vs Hash#fetch + block code

I have a bit of an issue with the

Hash#fetch with argument vs Hash#fetch + block code example.

My issue is that in order for the call to fetch NOT using the block to take place, the second argument needs to be evaluated. Depending on the complexity of the second argument ([*1.100]), you can get HIGH degree of variation in performance. An example like creating a new large array object, vs. a simple integer or string will change the results considerably, as it would with any method call where the parameters need to be evaluated BEFORE the call regardless of there usage during the method execution. A lot has to do with GC and recreation of objects vs primitives, vs recurring strings/symbols.

I suggest a more common example (my inference) would be to use something simpler for the second argument to make it an apples-to-apples comparison. This all stems from the fact that fetch does not USE the second argument or the block - and your example is biased that way, but any method call requires pre-evaluation of the arguments. SO either always use the argument AND block. or make the arguments simple enough that the work for the argument creation is not a timing element.

I do agree that not executing the block vs executing the block is comparative, but the measurements are extremely dependent on that second arguments evaluation, given the example is one that does NOT use the block call.

fastruby / fast-ruby

taking issue with Hash#fetch with argument vs Hash#fetch + block code #35