Avoid allocating strings for parsing comma separated int values

[Henr1k80]

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.

[github-actions]

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 🤖 🙂

[Henr1k80]

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]

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]

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]

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 🙂

[nul800sebastiaan]

I will note the removal of StringSplitOptions.RemoveEmptyEntries but as we're doing int.TryParse on these entries anyway, those would return false so all good there anyway.

[nul800sebastiaan]

Thanks again @Henr1k80 - I enjoyed the benchmark addition as well! 🙌