1
\$\begingroup\$

So I'm still new to making games that have a baseline for computer resource usage and I'm confused with my question. I can't find an answer anywhere on the internet so I'm here.

Simple Question:

Which uses more resources? x10 small scripts or x1 mega script?

Detailed Question:

Would x10 small scripts that consist of about 70 - 100 lines of code, be more resource consuming than x1 mega script containing about 700 - 1000 lines code?

||improve this question
\$\endgroup\$
  • 5
    \$\begingroup\$ Hi Black Cat, unfortunately this question doesn't seem to be about game development, but about programming in general. A good rule of thumb is not to worry about resources until you've actually encountered a problem while developing a game. Also when writing code, you should focus on making the code readable, instead of making it run fast. You'd be surprised how many more projects have been abandoned for being unmaintainable, than the number of projects that were abandoned for being slow. \$\endgroup\$ – TomTsagk Oct 8 '19 at 15:46
  • \$\begingroup\$ This sounds like a question you can answer for yourself by creating 10 small scripts and one mega script (or downloading free scripts documented online so you don't even have to invent the placeholder code), and measuring the RAM use when each is in play. What do you need from us that you can't determine for yourself in this way? Also, are you sure this is even a concern? The code itself will hardly ever be the main culprit for memory use. A single texture or music file might take up more RAM than the entire executable segment of your game attributable to scripts. Why does this matter? \$\endgroup\$ – DMGregory♦ Oct 8 '19 at 17:20
  • \$\begingroup\$ @TomTsagk great answer \$\endgroup\$ – virtouso Nov 23 '19 at 8:41
2
\$\begingroup\$

Scripts themselves take almost no RAM. You pretty much only have the cost of storing the CPU instructions (a few kilobytes at most, if your script is massive) and that's only once, it doesn't matter how many times the script is duplicated.

For comparison, a single bitmap sprite can to take up several megabytes. It's your assets that are going to be taking up RAM.

||improve this answer
\$\endgroup\$
1
\$\begingroup\$

When your game is compiled into bytecode, then all the script files disappear and are mixed into one giant mush of instructions (gross oversimplification, but it helps to get the idea). So it rarely matters how you organize your code across files for performance or memory consumptions. What matters is what that code actually does.

So when you wonder how to organize your sourcecode, then priority number one should always be readability or maintainability. See also the current hot network question "What are the benefits of multi-file programming?" on software engineering stack exchange

If you want to reduce the RAM footprint of your project, then you have to look at the actual content of your scripts and how you use them.

  • Every component of every game object has a bit of management overhead. So having one large MonoBehaviour will often be slightly more memory efficient than lots and lots of small MonoBehaviours which do the exact same thing.
  • This memory consumption is per instance of your script. If you put a MonoBehaviour on 1000 game objects, then it consumes 1000 times the amount of RAM if it's only on 1 game object (again a slight oversimplification, but it's a usable rule of thumb).
  • But the actual memory footprint of each MonoBehaviour instance depends on how much data it actually stores in its public, private and protected member variables. A component which has just a single integer will consume a lot less RAM than a component which contains a large array of long strings. So if you have some MonoBehaviours which contain a lot of data but that data is only required by a small subset of objects in your game, then extracting that data into a separate component which you then add more selectively can save you memory.

But in most real-world Unity projects, the main contributors to memory consumptions are not C# scripts. They are the build-in Unity components and the assets they use. So before you start to look at the memory footprint of your own scripts, first consider if you really need all of your assets, which Unity components you put on your game objects and if you use those components in a memory-efficient way. For example, did you know that every single time you change a material.color, Unity creates an entirely new Material asset in memory?

If you would like to know which parts of your game contribute for how much memory consumption, then you can use the Unity Profiler to find out.

||improve this answer
\$\endgroup\$
  • \$\begingroup\$ I will note that there is a sense that the "big mush" at the end does have a maximum size, but for most intents and purposes, that limit is too high to matter. I've only seen the error that it causes posted about twice, and there is a resolution (basically: create two mushes using assembly definitions) \$\endgroup\$ – Draco18s no longer trusts SE Nov 24 '19 at 4:40
0
\$\begingroup\$

i think there is no exact relation between lines of code and ram usage. scripts are translated to lower level instructions in many levels and in the end those instructions are fed to the cpu based on defining that which functions ore which part of code should be run in the same time.

ram is used to store data like variables in programm and stores files from hard disk to be accessible when needed

||improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.