search

ppy / osu

rhythm is just a *click* away!
https://osu.ppy.sh
MIT License
15.53k stars 2.31k forks source link

Reducing bloat when using osu! as a library #4241

Open holly-hacker opened 5 years ago

holly-hacker commented 5 years ago

Right now, osu.Game contains some code (such as difficulty and pp calculation) that can be very useful for many applications, but using it comes with the cost of bloat in terms of amount of files and filesize. This is due to the nature of .NET Standard and a large amount of code/resources that are not used when osu.Game is not used as a library. For me, using osu.Game and the 4 included rulesets through submodule makes my build directory over 200MB in size. The most notable bloat are native audio/rendering libraries (adding ~100MB in the x86 and x64 folders), osu-resources (adding 70MB in a single DLL), Humanizer (adding 44 directories to the application directory) and targetting .NET Standard (adding ~150 Microsoft. and System. DLLs ).

I don't really know of a perfect way to handle this, but here are the extremes:

  1. Forking osu! and removing unused code/dependencies. This is probably the easiest way and optionally allows you to retarget just .NET Framework, reducing the entire project to just the code you need. This isn't really the cleanest solution and makes it hard to keep up-to-date, but has a very small footprint.
  2. Asking the user to install the game and dynamically resolving the assemblies at runtime. The upside is that no additional disk space is used, downside is the requirement of having the game installed.
  3. Restucturing the project, separating logic from rendering. This is a relatively big change, and I'm not even sure in what way the restructure would happen so that the logic "project" has very little (and no circular) dependencies, if this is even the correct way to go.

I'm opening this issue to get some feedback on how to handle this, or to get some discussion going on how to improve it. I'm currently working on a project using osu.Game as a library, and shipping 200MB of libraries and resources that aren't being used doesn't seem right for a simple utility.

peppy commented 5 years ago

Most pieces are in place to already solve this. It's the reason nativelibs we're moved to their own nuget package. The next step would be to make osu.Game a nuget package, which is planned in the near future.

This is all low priority as it has no real world effect on anything. If you're distributing a binary you can already cull the unused files at your end, after all.