#im caching everything tools use once and
1 messages ยท Page 1 of 1 (latest)
personally i have an allergy to reflection XD, so i like to avoid it as much as possible
do you need it in editor or at runtime ?
do you cache it at startup or lazily ?
the con with reflection scans like this is usually performance, i had a case where on mobile similar thing was taking several seconds for example
the whole loop is run once, the info is cached as it loops for the future, we cant avoid reflection, serialization, tooling, runtime features rely on it
Also i still can't figure out a specific usecase for wanting to cache all the used types, but we don't need to go into details, you need it so yea, assembly + full name is ๐
Imho don't run the loop once, do lazily adds
In your case yea, you have costly calls at startup and possibly many unused types
also you have a dictionary of what ? Dict<string,Type> ?
with string being assembly+fullname ?
yes
188 ms the whole thing
lazy also has downsides
no control over when it will be invoked if its widely used
ie during a heavy frame, and you get a stutter
plus it means accessing and quering the same apis over and over for each call, even if you cache the result next call will still do the same work
again, it depends on how many assemblies you scan and device you are targeting and specific use-case
If you spare the warmup type sure it will be better later on
If you target fast loading times for mobile for example then maybe lazily won't hurt (or slicing it)
So when it comes to this point it starts having pros and cons
Cause you can get type lazily for the first time based on string and assembly load + get type and cache it there
Not trying to say you should not do it ๐, it just matters based on usecase
If you go with System.AppDomain.CurrentDomain.GetAssemblies() and then get all types that will take some time on certain devices
program will spend in total more time navigating reflection api
What is your target platform ?
desktop/consoles later
Ok so you have headroom for warmup and you can get back at it in case it makes issues (like if it loads too much)
Only thing i would recommend if you are not doing it already is to preallocate dictionary by giving it a size
will do
Also this sort of stuff can be moved to like an asynchronous flow as well so it happens in backgroung among other stuff, if you know for sure you won't need it for the first X seconds
But i still find it weird tbh mapping string to Type, usually you have access to type, never had this particular need and it's intriguing
I would see it used if you have it serialized and you need it from there
this is for unity internal types, no access to them by type
ah right, i though you meant internal as part of overall unity assembly not as protection level