Search Unity

Question Do unused installed packages have any effect?

Discussion in 'Package Manager' started by AmitChBB, Dec 4, 2022.

  1. AmitChBB

    AmitChBB

    Joined:
    Feb 16, 2021
    Posts:
    37
    Howdy everyone, I got a fairly simple question I'd love your feedback on.

    Say I got a Unity project with lots and lots of Unity packages installed, but no direct or explicit usage of any of them in my project. Will Unity's standard stripping remove them from my builds?

    In other words - is the reason many Unity packages don't come auto-installed in Unity because they just don't want to make downloading Unity/opening it bloated and slow?

    Thanks in advance!
     
  2. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    5,043
    Most should not affect the builds, but some might. If you don't use them, just remove them. That can also make the editor more snappy
     
  3. CodeSmile

    CodeSmile

    Joined:
    Apr 10, 2014
    Posts:
    5,882
    If completely unused a package's contents will not end up in your build.

    Additional upm packages have very little effect on the editor behaviour, minimal compile time and memory usage overhead in my experience.

    You will have an initial compile time for a package upon importing the package. And I believe every time when doing a build the package assemblies will be compiled too whether unused or not. Time depends on the package but typically expect fractions of a second here.

    Every script change causes an assembly reload, that means more assemblies to be reloaded the more packages you have but you won't notice this becoming any faster when only removing two or three unused packages. It's different if you have 10 packages installed and in use vs 50 packages in the project but maybe only using half of them - at that point you should consider a upm package cleanup.

    Note that this does NOT apply to Asset Store assets under the "My Assets" category!
    UAS assets are not installed as upm packages but imported as .unitypackage packages into your Assets tree hierarchy so they behave like any assets/scripts you may be creating and adding to your project yourself.

    Any UAS asset making use of Assembly Definition files should prevent the asset's scripts to be in your build if you don't use them by referencing said asmdef in your own asmdefs. However without any asmdefs the scripts of such assets will be compiled into the main assemblies. They may or may not be stripped from builds in that case (likely are but depends on various conditions afaik).

    You should generally try to keep your project as clean as possible with UAS assets (those located under "Assets" folder) and ensure all scripts including 3rd party are in an asmdef. Personally I move every UAS asset folder to the "Assets/Plugins" tree right after importing and 99% of the time this still works but sometimes I may have to manually fix a path or something. The plugin tree's scripts essentially and transparently compile into a "plugins" asmdef if any of the scripts in that tree don't have an asmdef in their folder or any of the parent folders.

    In the reverse, if you often change scripts, be sure they're not located under Plugins because this causes practically all dependent assemblies to recompile/reload on every change. Plugins is for scripts/assets that hardly ever change.
     
    maximeb_unity and AmitChBB like this.
  4. AmitChBB

    AmitChBB

    Joined:
    Feb 16, 2021
    Posts:
    37
    Wow, thank you so much for this in-depth answer! You really covered all the bases in clear and methodical language.