search

Fydar / AssetIcons

The public issue tracker and documentation for AssetIcons
https://fydar.dev/portfolio/asseticons
7 stars 0 forks source link

Unity 2019.2+: Significant overhead on Domain Reload due to AssetDrawerLibrary:BuildAssetDrawers() not using TypeCache #37

Closed gjroelofs closed 4 years ago

gjroelofs commented 4 years ago

Currently, AssetIcon reconstructs its internal IconProvider on Domain reloads by manually scanning all types in all assemblies. Especially the grabbing of all types from all assemblies is a costly operation. (I.e. measured to be 7+ seconds on a single 16+s compile cycle)

image

Locally, we have fixed this by implementing a class Attribute called AssetIconProviderAttribute that is set on any class that uses AssetIcon. BuildAssetDrawers() then uses TypeCache.GetTypesWithAttribute<AssetIconProviderAttribute>() instead which reduces overhead to sub 50ms. This was without modifying the logic that does the reflection based scanning of a type - it simply replaces the wholesale grabbing of all Types and Assembly scanning.

Arguably, this might be too invasive to require. One alternative is to use the TypeCache to at least access only ScriptableObjects, which will already bypass the costly Assembly access.

Fydar commented 4 years ago

I'm currently exploring only iterating on assemblies that have a dependency on AssetIcons.

I haven't heard of TypeCache before! That's pretty neat stuff. It isn't well supported yet, with only the LTS and latest versions of Unity having support for it.

But damn that's a long wait-time! Sorry about that! I'll work a fix for this into the 2.1.0 release :)

gjroelofs commented 4 years ago

@Fydar We fixed it locally, so no worries - and like I said it was a very quick fix.

I suspect that iterating over assemblies will only work pre-2019 / mid 2018 - versions that don't have proper support for Assembly Definitions. The default Assembly Definition configuration sets things up so that they get auto-referenced / injected, resulting in a massive web of interdependencies. (I.e. the main reason that most people say that adding ASMDefs into their projects results in slow downs....)

The approach of dependency scanning for anyone who doesn't know what's happening will result in long load times as well.

Honestly, I don't have a solution for you. Pre TypeCache we tried to be as selective as possible with Assembly scanning. An alternative is to go a route where you write out the found serializedobject types to file and load that in (with the obvious caveats that brings..)

IMHO - it's a widely known problem and I'd say that you're better off spending your development time on doing an #IFDEF UNITY_2019, and using TypeCache than trying to fix this for all versions. The problem is that if you fix it, there are several very popular assets that don't fix it either, (E.g.: Bolt, Peek, etc) and your only fixing a 10% optimization for others. 🤷