Resolved How does unity handle loading scripts?

Hello,

Imagine one had a 10 GB megaclass or megastruct containing only static fields and methods
and a bunch of 1 GB megaclasses and structs containing fields and methods to be instantiated during runtime (e.g. mono-behaviours and other classes / structs)

What would be the most effective way to prevent unity from loading these classes / logic when the application starts, and how would one load these asynchronously? Or is this somehow handled automatically?

 

Depends on the platform. With IL2CPP it is all (likely) bound into the executable. With other setups it might be some kind of DLL assembly that is loaded as Unity starts up.

Keep this in mind to help you reason about your investigation:

Your code is not the application. Unity is the application. Your code is just a minor guest at the party:

https://forum.unity.com/threads/res...-problem-when-using-ioc.1283879/#post-8140583

 

There's no advantage to imaging hypothetical situations that you're never going to encounter.

 

My brain refuses to imagine such madness!!
I did however imagine the sad developer who is forced to work with that setup left behind by his predecessor.

Imagine ten gigabytes of a class‘ fields saved as …. binary data! See that 10gb file with the odd extension? Yeah, that‘s the one. File.ReadAllBytes and you got yourself 10 gb of data in mem… whoops, this crashes on my 8 gb system. Weird.

No, sorry, I cannot imagine that. I automatically deviate trying to.

 

I can answer that part. Just make sure the corresponding .cs file is not located in the project‘s Assets tree.

 

True, but in my case it would still be applicable.
I made the example more extreme as to clarify the issue.

The idea is to have the application boot into the startup menu as fast as possible (only loading the menu logic and visuals), to start loading all actual gameplay specific logic / scripts on the background asynchronously when the player is still navigating the menu in a attempt to lower the waiting time.

I mean, in 99% of the cases the main menu of a game requires a mere fraction of the total code base.

I by no means know how unity structures the executable that it builds. Assuming by saying this you mean the scripts we write are not baked into the executable (which would make sense)? In any case even if the .exe file does not contain the code it might still load all code when booting?

Putting a .cs file outside of the assets tree? By this do you mean putting it outside of the assets folder? If this script would even compile in the build, how would we load this logic? I did a test in the editor, and my other scripts do not seem to recognise any code written in scripts outside of the assets folder and gives me the 'This s*** don't exist' error (which would make sense)?
I am terribly sorry if i misunderstood your reply.

 

Instead of guessing about weird ways of partial binary loading and destroying your app's wonderful simplicity and becoming the gatekeeper and maintainer of a HUGE fragile pile of noodle soup, take a step back and attach the profiler.

Once you have the profiler attached, find out what is taking your app so long to load. See below.

Hint: it probably won't be loading the code. It will almost certainly be textures or audio, at least after Unity has finished its startup.

Actual IPL-ing your script code is gonna be nearly instantaneous.

Besides, on many platforms ALL the code has to make it through whatever SPU or trusted computing digital content signature verification step is necessary before ANY of it will be marked as executable.

------------------------

DO NOT OPTIMIZE "JUST BECAUSE..." If you don't have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window -> Analysis -> Profiler

Failure to use the profiler first means you're just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://forum.unity.com/threads/is-...ng-square-roots-in-2021.1111063/#post-7148770

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Don't forget about the Frame Debugger either, available right near the Profiler in the menu system. Remember that you are gathering information at this stage. You cannot FIX until you FIND.

Notes on optimizing UnityEngine.UI setups:

https://forum.unity.com/threads/how...form-data-into-an-array.1134520/#post-7289413

At a minimum you want to clearly understand what performance issues you are having:

- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as "reimport all textures as 32x32 tiny textures" or "replace some complex 3D objects with cubes/capsules" to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you're properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

 

I love your instant detailed replies.
Taking this as the straight forward answer 'One could not really simply asynchronously load logic, for all of it needs to be in memory at the very start anyway'

I was simply wondering if it were possible to load logic asynchronously as the current project i work on takes less then half a second to boot, it at its current stage primarily being the startup UI, knowing my other less noteworthy projects take longer to boot whilst not loading more assets due to there more extensive codebase, i was wondering if one could preserve the very neat < 0.5 second booting time regardless of the games eventual codebase size...

Other than that i am aware of how to load any other form of data, (textures, audio, video, savedata, etc...) asynchronously as i personally pull all gamedata from disk using the asynchronous

System.IO

methods, further i guess the final product should not take up more then 5 seconds of startup booting time.

 

Code isn't the factor that increases load time. It's 99% resource loading or generating that affect app launch / scene load time. Your other projects simply referenced more assets (like meshes, textures, prefabs, etc) than your current project.

Sorry, that was sarcasm. You asked for an effective way not to have your code in the build. That's the most effective way: not adding it to the project.