summaryrefslogtreecommitdiff
path: root/benchmark/vm2_poly_same_method.yml
AgeCommit message (Collapse)Author
2020-04-13Unify vm benchmark prefixes to vm_ (#3028)Takashi Kokubun
The vm1_ prefix and vm2_ had had special meaning until 820ad9cb1d72d0897b73dae282df3793814b27e8 and 12068aa4e980ab32a0438408a519030e65dabf5e. AFAIK there's no special meaning in vm3_ prefix. As they have confused people (like "In `benchmark` what is difference between `vm1_`, `vm2_` and `vm3_`"), I'd like to remove the obsoleted prefix as we obviated that two years ago. Notes: Merged-By: k0kubun <takashikkbn@gmail.com>
2019-09-19reuse cc->call卜部昌平
I noticed that in case of cache misshit, re-calculated cc->me can be the same method entry than the pevious one. That is an okay situation but can't we partially reuse the cache, because cc->call should still be valid then? One thing that has to be special-cased is when the method entry gets amended by some refinements. That happens behind-the-scene of call cache mechanism. We have to check if cc->me->def points to the previously saved one. Calculating ------------------------------------- trunk ours vm2_poly_same_method 1.534M 2.025M i/s - 6.000M times in 3.910203s 2.962752s Comparison: vm2_poly_same_method ours: 2025143.9 i/s trunk: 1534447.2 i/s - 1.32x slower Notes: Merged: https://github.com/ruby/ruby/pull/2468