2 smaller scripts vs one large script

Will I see a performance improvement if I split my large script into 2 smaller scripts? Logically it makes sense to based on functionality but that's not really the question.
Does having 2 half sized scripts improve performance over one larger script? And then what about 3 or 4, when does it end?

Thanks,

You won't really see any performance change at all, unless both scripts are monobehaviours, in which case you will see a performance decrease. That said, the decrease is so small that you effectively need thousands of them to notice it have any meaningful effect.

3 Likes

The different in performance between 1 and 2 Monobehaviour scripts is negligible.

1 Like

[quote=“SamohtVII”, post:1, topic: 747811]
Will I see a performance improvement if I split my large script into 2 smaller scripts? Logically it makes sense to based on functionality but that’s not really the question.
Does having 2 half sized scripts improve performance over one larger script? And then what about 3 or 4, when does it end?

Thanks,
[/quote]
Performance is not the problem. Organization and modularization are the two main ones. Generally you ought to keep your class files as concise and modular as possible. My current project has 15 class files, I began writing last thursday. Each file is from 50 lines (minimum) to 160 or 200 lines in length.

Modules make things cohesive and can be loosely coupled (good things).

I’ve been there before, having a file with 300 or 700 lines of code. The problem you run into with a big file is it gets really difficult to manage both conceptually and organizationally.

1 Like

That is a great question. I'd actually like to see a technical answer on this: Something like ".0000001 ms extra time for two scripts vs. one script" or something like that. I don't know if anyone has ever tested it. Would be very interesting.

I think for 99.9% of people, it won't technically matter. The main thing that matters is if you can keep your code organized and working. Personally I have a few large scripts in all of my games, something like 1000 to 2500 lines of code in some of them. Which professionally probably isn't good at all......but if you can comment your code well and keep things really organized, you can use gigantic scripts if you want.

1 Like

[quote=“Velo222”, post:5, topic: 747811]
That is a great question. I’d actually like to see a technical answer on this: Something like “.0000001 ms extra time for two scripts vs. one script” or something like that. I don’t know if anyone has ever tested it. Would be very interesting.

I think for 99.9% of people, it won’t technically matter. The main thing that matters is if you can keep your code organized and working. Personally I have a few large scripts in all of my games, something like 1000 to 2500 lines of code in some of them. Which professionally probably isn’t good at all…but if you can comment your code well and keep things really organized, you can use gigantic scripts if you want.
[/quote]

Something tells me you’re writing ahem crummy code. If you need to comment things… I don’t think you’re naming things legibly nor “properly”, a term I use tentatively because properly is a subjective topic BUT the objective of it to produce clean and readable code that doesn’t necessitate commenting.

Many scripts don't really matter in terms of performance. Is just for human readability and convenience. Compiler will assemble them anyway, in appropriate way, for CPU/GPU to function.

Is easy to organize. But there were programming environments, where separate files weren't an options.

Modern script editors have capabilities, to collapse and quick jump to relevant scopes, within same file.

Also, comments exist for a reason. They can convey messages, where name of variable, method or otherwise is not enough.

Brief commenting what if, or for loop will be doing can be useful as well. Commenting at beginning, what script may be doing, can be informative too. But is harder to maintain, when scripts evolves. Also can comments can nicely divide script into sections.

For example having multiple methods in one script. Like math. And commenting off vectors, trigonometry etc.

Coming back next year to scrip, can be very time consuming, when there are 0 comments. Regardless of methods, fields etc., naming.

1 Like

[quote=“Velo222”, post:5, topic: 747811]
That is a great question. I’d actually like to see a technical answer on this: Something like “.0000001 ms extra time for two scripts vs. one script” or something like that. I don’t know if anyone has ever tested it. Would be very interesting.

I think for 99.9% of people, it won’t technically matter. The main thing that matters is if you can keep your code organized and working. Personally I have a few large scripts in all of my games, something like 1000 to 2500 lines of code in some of them. Which professionally probably isn’t good at all…but if you can comment your code well and keep things really organized, you can use gigantic scripts if you want.
[/quote]

…My dude, you’ve got scripts the size of some of my entire smaller projects. That’s not… great.

5 Likes

[quote=“Murgilod”, post:8, topic: 747811]
…My dude, you’ve got scripts the size of some of my entire smaller projects. That’s not… great.
[/quote]

If it works, it works. Of course it’s great to keep scripts modular, I do that as well. But sometimes a “module” gets large, especially if it’s a large or complex game. I don’t have other people working on that particular project, so as long as I can understand it every time I go back to it, and it functions correctly, that’s all that matters to me lol.

1 Like

[quote=“Velo222”, post:9, topic: 747811]
If it works, it works. Of course it’s great to keep scripts modular, I do that as well. But sometimes a “module” gets large, especially if it’s a large or complex game. I don’t have other people working on that particular project, so as long as I can understand it every time I go back to it, and it functions correctly, that’s all that matters to me lol.
[/quote]

This is a terrible attitude to take because monolithic scripts like this make debugging and refactoring a major nightmare. Even my large, complex special rendering systems don’t get to that size.

2 Likes

[quote=“Murgilod”, post:10, topic: 747811]
This is a terrible attitude to take because monolithic scripts like this make debugging and refactoring a major nightmare. Even my large, complex special rendering systems don’t get to that size.
[/quote]

Well, I’ll take your advice into consideration. But it works, so I don’t know what to say. I’ve been able to debug it just fine. And as for refactoring, I just havn’t had to refactor that much, and it hasn’t raised any issues. I know, it’s bad form, so I get what you’re saying. But to me, the end goal is that it works right?

I actually think there are very much times and places for large functions - that is a function that clocks in at like 500+ lines. It really depends though, and most of the time when people do stuff like that they're making a mess.

Some of the code that I found easiest to work with given high complexity was a 700 line function I wrote to handle camera logic. I revised it and added features, etc, and found it quite easy to deal with. Much easier than if I had split it up.

Again though, I wouldn't recommend this kind of thing in general - but there is a time and a place.

1 Like

[quote=“Velo222”, post:11, topic: 747811]
Well, I’ll take your advice into consideration. But it works, so I don’t know what to say. I’ve been able to debug it just fine. And as for refactoring, I just havn’t had to refactor that much, and it hasn’t raised any issues. I know, it’s bad form, so I get what you’re saying. But to me, the end goal is that it works right?
[/quote]

“Works” does not automatically translate to “works well.” Pulling out works, but you should probably just wrap it up instead.

4 Likes

[quote=“Murgilod”, post:13, topic: 747811]
“Works” does not automatically translate to “works well.” Pulling out works, but you should probably just wrap it up instead.
[/quote]

Well, you’re right. I’m not going to argue with that. :smile:

[quote=“SamohtVII”, post:1, topic: 747811]
Will I see a performance improvement if I split my large script into 2 smaller scripts? Logically it makes sense to based on functionality but that’s not really the question.
Does having 2 half sized scripts improve performance over one larger script? And then what about 3 or 4, when does it end?

Thanks,
[/quote]

Optimisation Guide In Unity https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity.html

Step 1. Profile…

2 Likes

I like big scripts and I can not lie.

Some of my functions (methods, whatever, like I care) are freaking huge. Some of my scripts are wickedly long. Come at me bro.

5 Likes

I've always seen that a class(like OOP style class, Monobehaviours are a bit different) should do one thing, and one thing only. That paradigm means that most if not all of our classes are too big, though I'm not convinced this "rule" is that big a deal. The point stands though, that we should try to keep things organized, etc... It can often make sense to split a script/class into separate parts, especially if either of those parts could be reused elsewhere. For example, if a player ship and an enemy ship have the same movement patterns/controls, but one is player controlled and the other AI controlled, I would put the movement in one class, and then have separate classes which then access that class, meaning you don't have duplicate code anywhere.

Another thing to consider...besides the abovementioned point that you need to PROFILE before optimizing(pre-optimization is evil, etc... etc...). If you are using Unity, you are already technically taking a performance hit. This applies to any generic engine(UE4, Gamemaker, anything). This doesn't mean that the performance isn't good enough, as when used correctly the performance is almost always good enough. I'd say splitting scripts up where it makes sense is the same way. So you might lose a percentage of a millisecond here and there....totally worth keeping the sanity with organization of the project.

1 Like

I like to budget some time refactoring any time a class gets too long. Several smaller classes will usually be far easier to maintain than one giant class.

Similarly, I always try to keep every function small enough to fit onscreen without scrolling. It is harder to debug functions when you have to scroll to see it all.

In addition to scrolling, large function tend be too long to name effectively. If you have a really long function that needs comments just to make sense, then you should break it down into several smaller well named functions with narrow scope. A bunch of small, well named functions can replace the need for most comments.

1 Like

As for purely performance considerations, there is significant overhead to having many thousands of objects with Update functions on all of the scripts on those objects. However, having three or four classes instead of one will not affect performance in a meaningful way when dealing with a low number of objects.

Side note:
Having 10,000 extra Update functions in a scene will affect performance by a measurable amount. If you need to have 10,000 objects moving around in your scene, use ECS instead of instantiating 10,000 objects with scripts attached to each one.

2 Likes

[quote=“Antypodish”, post:7, topic: 747811]
Also, comments exist for a reason. They can convey messages, where name of variable, method or otherwise is not enough.

Brief commenting what if, or for loop will be doing can be useful as well. Commenting at beginning, what script may be doing, can be informative too. But is harder to maintain, when scripts evolves. Also can comments can nicely divide script into sections.
[/quote]
Indeed. And often sometimes, in a team, one person will make choices that are non-obvious because they support a larger architecture or some longer term plan. Our lead often puts these in if something seems weird, he will comment that it is works into a bigger piece.

Although it is sort of weird, our team is fully distributed so our comments often work like a context-based chat system. I’ll go in to wire something or build out vfx or whatever and find implementation notes specifically for me (and I do the same). Oddly we have found this works really well. Several of us are in different time-zones, so we pass work back and forth. For example, If our game play engineer needs to tell me something super specific about a new feature and the way he implemented it, he’ll leave me messages in code, and I may ask questions or reply to him, in the code. If he were to slack or email or trello it to me, I may or may not see or remember it when I work on that part. In the code, it is right there in front of me, exactly when I need it.

6 Likes