Skip to content
New issue

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

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

Already on GitHub? # to your account

Add sliceHeader for zero-copy parsing of message headers, use for client info #6453

Merged
merged 1 commit into from
Feb 4, 2025

Conversation

neilalexander
Copy link
Member

@neilalexander neilalexander commented Feb 4, 2025

In the various places that we are handling client info from headers, like when queuing and pulling from the JS API queue or due to the service export, we could safely refer to the underlying header slice, instead of making a copy as getHeader() does today.

This PR adds a new sliceHeader() that merely slices the input header instead, reducing copies considerably in any system where there is heavy usage of JS API requests.

Signed-off-by: Neil Twigg neil@nats.io

@neilalexander neilalexander requested a review from a team as a code owner February 4, 2025 18:33
server/client.go Outdated
index++
}
return value
return hdr[start:index]
Copy link
Member

Choose a reason for hiding this comment

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

Should we also set cap here? That way if someone does try to do an append it will force a copy at that point?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, done.

…lient info

Signed-off-by: Neil Twigg <neil@nats.io>
Copy link
Member

@derekcollison derekcollison left a comment

Choose a reason for hiding this comment

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

LGTM

if v == nil {
return nil
}
return append(make([]byte, 0, len(v)), v...)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe do allocation and copy? Unless we know append is as efficient for larger sizes..

Copy link
Member Author

Choose a reason for hiding this comment

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

It's just as efficient when the capacity is preallocated, so just makes for a tidier one-liner.

@derekcollison derekcollison merged commit 29fbf46 into main Feb 4, 2025
5 checks passed
@derekcollison derekcollison deleted the neil/sliceheader branch February 4, 2025 20:00
neilalexander added a commit that referenced this pull request Feb 6, 2025
Includes the following:

- #6406
- #6412
- #6408
- #6416
- #6425
- #6424
- #6438
- #6439
- #6446
- #6447
- #6448
- #6449
- #6450
- #6451
- #6452
- #6453
- #6456
- #6458
- #6457
- #6459
- #6460
- #6461

Signed-off-by: Neil Twigg <neil@nats.io>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants