Consider limit-tester maps #55
Description
Some beatmaps just aren't designed for gameplay but rather to limit-test what osu! puts up with. These maps may gravely affect difficulty- and performance calculation.
osu! handles these by simply timing out while processing. The analogous would be to spawn a thread and synchronize it through a timeout mechanism. Not only would that bring an absurd amount of complexity (pooling, testing, multithreading is hard) into rosu-pp, it would also prevent architectures without notion of threads or time (see wasm) to use it.
An alternative would be to provide a method on Beatmap that applies some heuristic to judge whether a map is suspicious. If difficulty calculation would call this method independently, it should probably return an error on suspicion (note: breaking api change) which also means that it would not be possible to calculate attributes on these maps at all despite technically being possible - so this doesn't seem like the way.
To me, the more appealing option is to let users decide what to do with such a method. If they are worried about such very rare malicious maps, they will need to call the heuristic every time before calculating attributes which also appears rather tedious and inconvenient but it seems like the way to go(?).
A related tangent is the raw_strains feature. It essentially causes a performance penalty for almost all maps to be able to handle very rare malicious maps which seems very sad. Once a heuristic method is added, it would probably make sense to use raw strains by default and get rid of the feature. Maps that would benefit from the previous optimization should then be flagged as suspicious so users can decide if they want to risk calculating attributes and running out of memory while doing so.
Note that removing a feature is a breaking change
Checklist
- Add heuristic method feat: add suspicion heuristic #56
- Remove
raw_strainsfeature (i.e. await next breaking release)