On Mon, 17 Oct 2022 09:38:01 GMT, Сергей Цыпанов <d...@openjdk.org> wrote:
>> I saw this code many times and always thought that it exists for performance >> purposes, to avoid extra indirection via likely megamorphic naturalOrder >> comparator which will slow down the operations on common path. I think such >> a simplification could be accepted only if accompanied by a properly written >> benchmark (which actually emulates megamorphic callsite) which shows no >> performance regression. > > @amaembo you mean we should have a benchmark measuring a `TreeMap.get()` with > lots of implementations of Comparators or Comparables? @stsypanov all operations involving the code paths touched by your refactorings. Well, get() is the most interesting one. Comparable.naturalOrder() should be actually used in many other contexts (e.g., in setup phase of the benchmark) often enough to pollute the type profile. Well, probably there are some compiler control options to automate this but I'm not aware. I would also check inlining log to ensure whether comparator is devirtualized and inlined or not. If inlined, then it's unlikely that you've polluted the type profile successfully. ------------- PR: https://git.openjdk.org/jdk/pull/9901
