Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perf: improve hexToBase64 #3178

Merged
merged 5 commits into from
Aug 22, 2022

Conversation

seemk
Copy link
Contributor

@seemk seemk commented Aug 18, 2022

Which problem is this PR solving?

Improve hexToBase64 which is used in OTLP exporters to convert span and trace IDs. The previous implementation created a lot of garbage which had to be cleaned up by the GC. Besides the GC overhead, the old version was slow (see the table).

Why not use Buffer.from(hexStr, 'hex') instead? It turned out the handwritten one is faster (500k random inputs, Node 16.15):

Version Avg (ns) diff
hexToBase64 - new 1349 1.0
Buffer.from(str, 'hex').toString('base64') 1995 1.48
hexToBase64 - old 3759 2.78

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added

@seemk seemk requested a review from a team August 18, 2022 19:15
@codecov
Copy link

codecov bot commented Aug 18, 2022

Codecov Report

Merging #3178 (13471d7) into main (406a059) will decrease coverage by 1.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #3178      +/-   ##
==========================================
- Coverage   93.18%   92.15%   -1.04%     
==========================================
  Files         196       87     -109     
  Lines        6431     2497    -3934     
  Branches     1359      547     -812     
==========================================
- Hits         5993     2301    -3692     
+ Misses        438      196     -242     
Impacted Files Coverage Δ
...s/opentelemetry-core/src/platform/node/sdk-info.ts 0.00% <0.00%> (-100.00%) ⬇️
...opentelemetry-core/src/platform/node/globalThis.ts 0.00% <0.00%> (-100.00%) ⬇️
...pentelemetry-core/src/platform/node/performance.ts 0.00% <0.00%> (-100.00%) ⬇️
...emetry-api-metrics/src/platform/node/globalThis.ts 0.00% <0.00%> (-100.00%) ⬇️
...lemetry-resources/src/detectors/ProcessDetector.ts 31.81% <0.00%> (-68.19%) ⬇️
...perimental/packages/otlp-exporter-base/src/util.ts 79.41% <0.00%> (-17.65%) ⬇️
...ckages/opentelemetry-exporter-zipkin/src/zipkin.ts 84.48% <0.00%> (-15.52%) ⬇️
...lemetry-resources/src/detectors/BrowserDetector.ts 93.33% <0.00%> (-6.67%) ⬇️
...ntelemetry-core/src/platform/node/hex-to-base64.ts
.../opentelemetry-sdk-metrics/src/aggregator/index.ts
... and 107 more

@dyladan
Copy link
Member

dyladan commented Aug 22, 2022

How did you generate the above timings?

@dyladan
Copy link
Member

dyladan commented Aug 22, 2022

The old implementation doesn't make any sense to me. Why did it bother doing the hex to ascii conversion before Buffer.from? I know probably nobody here has an answer for this but I haven't looked at this code in so long it is just making me scratch my head a bit why that choice was made.

const hexPair = hexStr.substring(i, i + 2);
const hexVal = parseInt(hexPair, 16);
hexAsciiCharsStr += String.fromCharCode(hexVal);
const buf = Buffer.alloc(hexStr.length / 2);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alloc is probably the most expensive part of this function at this point. Preallocating common lengths likely results in a significant speedup

const buf8 = Buffer.alloc(8)
const buf16 = Buffer.alloc(16)

function hexToBase64(hexStr) {
    let buf;
    if (hexStr.length === 16) buf = buf8;
    else if (hexStr.length === 32) buf = buf16;
    else buf = Buffer.alloc(hexStr.length / 2);

    let offset = 0;

    for (let i = 0; i < hexStr.length; i += 2) {
        const hi = intValue(hexStr.charCodeAt(i));
        const lo = intValue(hexStr.charCodeAt(i + 1));
        buf.writeUInt8((hi << 4) | lo, offset++);
    }

    return buf.toString('base64');
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point, added in 95966fa

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used node-microbenchmark and the speedup is definitely real

Iterations: 375
  +-------------------------+--------------------+----------------------+-----------+
  | Name                    | nano seconds       | milli seconds        | Slower by |
  +-------------------------+--------------------+----------------------+-----------+
  | testHexToBase64Prealloc | 8349.088           | 0.008349088          | fastest   |
  | testHexToBase64         | 12648.157333333333 | 0.012648157333333333 | 1x        |
  +-------------------------+--------------------+----------------------+-----------+

@seemk
Copy link
Contributor Author

seemk commented Aug 22, 2022

How did you generate the above timings?

Measured each of these calls with process.hrtime.bigint() and kept a statistics table running for a sample app that was generating traces and spans. So the only input were either 16 or 32 character length hex strings (500k of them)

@legendecas did additional benchmarking in one of the previous resolved comments

@seemk
Copy link
Contributor Author

seemk commented Aug 22, 2022

The old implementation doesn't make any sense to me. Why did it bother doing the hex to ascii conversion before Buffer.from? I know probably nobody here has an answer for this but I haven't looked at this code in so long it is just making me scratch my head a bit why that choice was made.

I have no idea, it seems to have slipped in as part of a larger PR 🤔

@seemk
Copy link
Contributor Author

seemk commented Aug 22, 2022

Not sure what's up with the codecov %, possible to rerun?

@dyladan
Copy link
Member

dyladan commented Aug 22, 2022

Not sure what's up with the codecov %, possible to rerun?

our code coverage has been weird recently. I can see which paths are tested here so i'm not worried about it

@dyladan dyladan merged commit 9b5149c into open-telemetry:main Aug 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants