2026 Q2 SR & PP release

[tsunyoku]

osu, taiko and catch have deployable changes this time around.

There are 2 new databased difficulty attributes for osu ruleset.

• ReadingDifficulty
• ReadingDifficultNoteCount

Newspost: ppy/osu-wiki#14752

[peppy]

I've applied all my pending optimisations.

For 10,000 computations of osu! beatmap (no beatmap parsing)

master: 32,336 ms / 13,463 mb allocs
This PR (before optimisations): 52,882 ms / 17,521 mb allocs
This PR (now): 41,195 ms / 10,241 mb allocs

[peppy]

!diffcalc
RULESET=osu
OSU_A=https://github.com/ppy/osu/tree/pp-dev-no-optimisations
OSU_B=#37850

[github-actions]

Difficulty calculation failed: https://github.com/ppy/osu/actions/runs/28331275763

[peppy]

diffcalc failure was out of disk space, re-running.

[peppy]

I'm setting up a background run of diffcalc, just running on my own pc for now because i foresee getting the pp-dev branch merged and nugetted taking CI / process time. will be done in a way where results can be transferred to production if all looks good.

I've already gone through them and shared my general discontent at where things are, largely due to lacking documentation and added complexity (see https://discord.com/channels/546120878908506119/1283498831224373278 history for those with access. discussion once again happening in many places which aren't public for unknown reason)

Main themes:

• there's no inline documentation (stanr says "check PRs instead inline would be messy" but i'm sure we can all agree to disagree with that)
• things were hugely inefficient mostly fixed, but some skills are still doing large iterations over all hitobjects per hiobject
• the work that diffcalc is doing is being split more and more over different methods, to the point it's hard to track what is doing anything, see exhibit a:

master	this PR

master was already pretty weird, but the new code is now doing work in:

• getDifficultyHitObjects (this now has ruleset specific somewhat-intensive calculations going on, setting up stored values for future steps, see computeSliderCursorPosition and setDistances)
• ProcessInternal of multiple Skills (with several sub levels beneath that)
• ObjectDifficultyAt of multiple Skills (how is this different from the above? 🤷)
• CreateDifficultyAttribs (final summary calculations, regularly drawing from the previous calculations even though there's no guaranteed ordering documented anywhere)

The overall flow is incomprehensible without days of learning the code, which is what I did this week. It feels to me nothing short of what I've seen in a past life when developers make a system overly convoluted to ensure job security. I don't think that's the case here, but it's at that level.

Before any further complexity is added, there needs to be a large refactor, driven with input from someone on the core team, bringing things back in line with sanity.

Merge pending spreadsheet results.

@ppy/team-client If anyone feels the need to review the changes before merge then now's your chance (let me know if that's happening).

[bdach]

If anyone feels the need to review the changes before merge then now's your chance (let me know if that's happening).

I have no intention of doing this.

[smoogipoo]

Can we not do this? This hasn't even been properly benchmarked - the benchmark references the method above which just redirects through... Math.Pow()??

Here's the results of this int exponent version:

| Method       | Exponent | Mean      | Error     | StdDev    |
|------------- |--------- |----------:|----------:|----------:|
| MathPow      | 0        | 0.3504 ns | 0.0012 ns | 0.0010 ns |
| DiffUtilsPow | 0        | 0.5246 ns | 0.0035 ns | 0.0029 ns |
| MathPow      | 1        | 0.3508 ns | 0.0015 ns | 0.0013 ns |
| DiffUtilsPow | 1        | 0.5416 ns | 0.0080 ns | 0.0067 ns |
| MathPow      | 2        | 0.3608 ns | 0.0098 ns | 0.0091 ns |
| DiffUtilsPow | 2        | 0.5400 ns | 0.0073 ns | 0.0057 ns |
| MathPow      | 3        | 0.3525 ns | 0.0152 ns | 0.0127 ns |
| DiffUtilsPow | 3        | 0.5527 ns | 0.0140 ns | 0.0124 ns |
| MathPow      | 4        | 0.3538 ns | 0.0073 ns | 0.0064 ns |
| DiffUtilsPow | 4        | 0.5483 ns | 0.0151 ns | 0.0134 ns |
| MathPow      | 5        | 0.3369 ns | 0.0042 ns | 0.0035 ns |
| DiffUtilsPow | 5        | 0.5472 ns | 0.0047 ns | 0.0044 ns |

i.e. Unless I'm missing something, it's a regression in all cases.

[peppy]

Sorry, benchmark in PR is a very outdated version which doesn't actually run the work, will push a fix.

[github-actions]

Difficulty calculation failed: https://github.com/ppy/osu/actions/runs/28331275763

[tsunyoku]

master was already pretty weird, but the new code is now doing work in:

• getDifficultyHitObjects (this now has ruleset specific somewhat-intensive calculations going on, setting up stored values for future steps, see computeSliderCursorPosition and setDistances)
• ProcessInternal of multiple Skills (with several sub levels beneath that)
• ObjectDifficultyAt of multiple Skills (how is this different from the above? 🤷)
• CreateDifficultyAttribs (final summary calculations, regularly drawing from the previous calculations even though there's no guaranteed ordering documented anywhere)

For my own sanity, you are aware that most of this was the case in master and was not changed by this release cycle?

ProcessInternal and ObjectDifficultyAt are new and things have been jigged around there, but everything else mentioned has been the case for a lot longer.

[peppy]

For my own sanity, you are aware that most of this was the case in master and was not changed by this release cycle?

Yes, see the first line of my text that you quoted.

"Used to be bad, now is worse, next time things have got to get better because we can't go further in this complexity direction" is what I'm getting at.

[peppy]

!diffcalc
RULESET=osu
OSU_A=https://github.com/ppy/osu/tree/pp-dev-no-optimisations
OSU_B=#37850
RANKED_ONLY=1

[github-actions]

Target: #37850
Spreadsheet: https://docs.google.com/spreadsheets/d/1BM3HzGazyvBbYuUCVwP926cWHjBfbtiWZP4JQaaHs7M/edit