#im caching everything tools use once and

1 messages ยท Page 1 of 1 (latest)

clever jungle
#

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

molten crow
#

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

clever jungle
#

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

molten crow
#

to accelerate any future queries, what are the downsides?

#

memory?

clever jungle
#

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 ?

molten crow
#

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

clever jungle
#

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

molten crow
#

program will spend in total more time navigating reflection api

clever jungle
#

What is your target platform ?

molten crow
#

desktop/consoles later

clever jungle
#

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

molten crow
#

will do

clever jungle
#

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

molten crow
#

this is for unity internal types, no access to them by type

clever jungle
#

ah right, i though you meant internal as part of overall unity assembly not as protection level