RFR: 8352075: Perf regression accessing fields [v28]
Johan Sjölen
jsjolen at openjdk.org
Tue Jun 10 15:47:44 UTC 2025
On Tue, 10 Jun 2025 15:15:34 GMT, Radim Vansa <rvansa at openjdk.org> wrote:
>> I think you misunderstand me, as what I'm proposing wouldn't requre creating an array in `create_search_table`.
>>
>> I'm saying that you do this:
>>
>> ```c++
>> // Note: we require the supplier to provide the elements in the final order as we can't easily sort
>> // within this method - qsort() accepts only pure function as comparator.
>> void PackedTableBuilder::fill(u1* table, size_t table_length, Supplier &supplier) const {
>> Pair<uint32_t, uint32_t> kvs[4];
>>
>> size_t offset = 0;
>> size_t len_read = 0;
>> while (len = supplier.next(kvs, 4)) {
>> // len tells you how many of the full capacity of kvs was used.
>> }
>> }
>>
>>
>> Now each call of `Supplier::next` gives you up to 4 elements, quartering the amount of virtual calls necessary.
>>
>>>Alternatively, we could replace virtual calls with templated fill method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?
>>
>> Sure, you can try that out.
>>
>> To be clear, I am only asking: Are virtual calls expensive enough here that not having them, or amortizing their cost, something that makes the performance better?
>
> The earlier version of this PR was not abstracting out PackedTable* so there were no virtual calls. In both the CCC.java and undisclosed customer reproducer I don't see a significant difference in performance - these involve whole JVM startup, so the efficiency of code with linear complexity is probably under the radar. If we want to optimize the hack out of it - yes, there would be space for that, maybe at the cost of maintainability and/or reusability.
> TLDR: I don't have a (micro)benchmark that would prove one thing is better than the other.
Alright, if you can't observe a difference then don't change a thing :-).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2138248072
More information about the serviceability-dev
mailing list