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

Avoid allocating strings for parsing comma separated int values #18199

Open
wants to merge 3 commits into
base: contrib
Choose a base branch
from

Conversation

Henr1k80
Copy link
Contributor

@Henr1k80 Henr1k80 commented Feb 2, 2025

Parse integers directly from stack allocated spans.

Prerequisites

  • I have added steps to test this contribution in the description below

Description

I suppose umbraco do quite a few GetPermissionsForPath for every page view?
Especially if a site menu is rendered? 😅

The array of strings from the "normal" string Split are all allocated on the heap, and needs to be garbage collected at some point.
That is, both all the strings and also array that contains them, and they are not used outside this method.

Here, I parse integers from spans of the string, none of the beforementioned intermediate parsing allocations are needed.

Only drawback is that we do not know the destination max length, so we might need to resize the list, or a micro 🤏🏻 overallocation.
To make sure this tweak is worthwhile, I made a benchmark.

Compared to the production LINQ
71% reduced allocations
56% reduced execution time

Compared to the already improved #18048
62% reduced allocations
32% reduced execution time

The most important improvement here, is less garbage collection work.
A few dozen μs in execution time are only measurable in BenchmarkDotNet
Scalability wise, is where the win is, less cleanup for the garbage collector.
Less GC pauses will result in smaller response time averages.

Sorry, something went wrong.

…e them directly from spans. Added benchmark to prove it is more efficient
Copy link

github-actions bot commented Feb 2, 2025

Hi there @Henr1k80, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

  • It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
  • The automated tests all pass (see "Checks" tab on this PR)
  • The level of security for this contribution is the same or improved
  • The level of performance for this contribution is the same or improved
  • Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
  • If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
  • 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

Sorry, something went wrong.

@Henr1k80
Copy link
Contributor Author

Henr1k80 commented Feb 2, 2025

A small mention of my favorite reviewer @AndyButland, this is related to the previous review #18048

So IF you have time, this is probably just the thing for you?

P.S.: It shows the price of LINQ

@AndyButland
Copy link
Contributor

Looks another convincing update @Henr1k80. My only comment is on where you started out:

I suppose umbraco do quite a few GetPermissionsForPath for every page view?
Especially if a site menu is rendered? 😅

I don't believe this method is used in that situation - rather this is used in the backoffice, to check the permissions for the editor. So it's not part of front-end rendering and hence is going to get called much less often than perhaps you anticipated in going by the name of the method.

Given that, does that change your view on whether including this is valuable? I'm still happy to include it given we have the method under test and it's unlikely to need functional changes. But we need to have an eye as well on keeping the code simpler for maintenance.

@mikecp
Copy link
Contributor

mikecp commented Feb 3, 2025

Thanks a lot @Henr1k80 for this improvement 👍
And thanks @AndyButland for your first feedback 😉

A member of the core collaborators team will have a look at it soon. In the meantime, have a great Monday!

@Henr1k80
Copy link
Contributor Author

Henr1k80 commented Feb 3, 2025

Yeah, sorry @AndyButland , I did an assumption based on the method name and the that is was in Core.Services.UserService 😅

I can hardly see where it is used, if I dive deeper 😂
But, yeah, it looks like it is not used in the front-end, only backoffice.

I promise I will not spend more time nitpicking this method 🙂

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
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.

None yet

4 participants