Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

CSHARP-5611: Eliminate the temporary byte array allocation in ObjectId.ToString #1706

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
Loading
from

Conversation

ugurpelister
Copy link

ObjectId's ToString method is among the highest of all highly frequently used methods in this library. The temporary byte array allocation that takes place inside ToString is an unnecessary one that adds workload on the GC.

Given that the same functionality can be achieved by a leaner implementation for .NET6+ and .NETStandard2.1, we propose a Span-based implementation for these two platforms so that the resulting string can by created without leaving any garbage. The old implementation can continue to be used on .NET Framework 4.7.2.

@ugurpelister ugurpelister requested a review from a team as a code owner June 7, 2025 18:43
@ugurpelister ugurpelister requested review from sanych-sun and removed request for a team June 7, 2025 18:43
@ugurpelister ugurpelister marked this pull request as draft June 7, 2025 19:05
@ugurpelister ugurpelister marked this pull request as ready for review June 7, 2025 19:21
@damieng
Copy link
Member

damieng commented Jun 8, 2025

I think like the previous two PRs for this there this is going to regress on big endian for very real-world gains.

@ugurpelister
Copy link
Author

I think like the previous two PRs for this there this is going to regress on big endian for very real-world gains.

Specifically comparing to the existing implementation of ToByteArray, what do you think would cause the big endian-related regress in this span implementation?

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.

2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.