Nothing, it's a benchmark. It's the nature of benchmarks to consider code in isolation, with as minimal side-effects as possible to measure the differences. It doesn't measure a whole program, or what affect each solution may have.
However, this is also the nature of premature and micro-optimizations. The point of the benchmark was simply to show that assuming keys/values is slower than each is not always correct. Any decisions beyond that should only be measured based on actual code, with a profile, and an indication that this part of the code is the bottleneck. | [reply] |
Nothing, it's a benchmark. It's the nature of benchmarks to consider code in isolation, with as minimal side-effects as possible to measure the differences.
Then your benchmark is broken. All you've done is bias the benchmark to favour your opinion, which is utterly pointless.
Once you start doing something with the keys and values, avoid creating large arrays is a part and parcel of what makes each more efficient.
And for your "too many caveats" argument: the semantics are clearly defined and obvious. If they are too complicated for you to bother with that's your call, but others may be less stressed by that 'complexity'.
Me for example. I mention the possibility here because *I* find it useful, and others might also.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Then please, implement a benchmark that exhibits the savings you are concerned about. My benchmark was simply to show that it was not a given that 'each' is faster (or better). The reason they are building arrays is to validate each function does the same thing; given they are both doing the same thing in that regard, the only difference is in the raw speed of an 'each' (and push) loop vs. getting a list of values from keys and values.
Indeed, the semantics of 'each' are clearly defined and obvious. The results of those semantics in a large body of code is not. It's essentially an action-at-a-distance effect. Understanding how that became a problem (in the event it does), and how to find what did it, can make for a very difficult bug to track down.
This is essentially the same reason global variables are generally avoided. If you can always avoid the problems with 'each', and do so when others are looking at and maintaining your code, please, let us all know how you accomplish it; it would go a long way to redeeming 'each' in my opinion, at least.
| [reply] |
