Optimization Question about Singleton

Questions & Answers
1

Hi,

I have a GameObject with a script with a Singleton pattern. And I need to call a function in an other object.

But what’s the best thing to do :

  • Call for :

MyScript.Instance.MyFunc();

  • Store my Singleton’s GameObject in my calling object and call it like this :

myScript.MyFunc();

What is the best thing to do in term of performance and optimizations.

Thanks a lot.

3

There is no need to store the instance variable locally. It’s already stored in the singleton, so creating a local reference to the instance is just redundant, unless you intend to be able to dynamically swap to a different singleton that implements the same interface. (See abstract factory pattern)

There is two main ways:

#1. use an Instance method or readonly property, like you described.

eg. MyScript.Instance.MyFunc()

#2. create static wrapper fuctions in your singleton class, which call your instanced functions.

eg. MyScript.MyFunc() (note ‘MyScript’, not ‘myScript’)

Here is a pseudo example of a wrapper function in case I’m not explaining clearly:

public static void MyScript.MyFunc() {
    MyScript.Instance.MyFunc();
}

I prefer #2 but using Instance makes your code self-documenting, which is never a bad thing. Using Instance makes it clear to anyone reading your code that you are making a call to a singleton. Using #2, its unclear of it’s a static class or a singleton.

Depending on how your singleton is used, you may prefer one method over the other. If you create your singleton once and never destroy the instance until the application terminates, then #2 is a good choice. This is normally how singletons are used in Unity, as some sort of object manager. It’s not important if it’s static or singleton in this case.

Hope that helps.

2

In fact here’s the “really long and final” discussion on the simple, reliable and now inevitable “grid” system…

cheers!

An endless question in Unity development is how to handle singletons and singleton-like structures, the efficiency thereof, and the fact that coroutines and arguably the whole general nature of Unity just, in many ways, hates singletons. It’s just so unportable, so many assumptions, etc - we just got in to a big mixup with a code base working with another dev where singletons didn’t fit together etc.

I only like things that are extremely simple, over on this question,

I outline something we do in every project now which is little more than a linguistic trick. But it solves ALL problems in a lovely way. The only downside is, essentially, you have to add one extra “.” in those calls. But it’s just so tidy. I like it more and more.

Here is the whole answer:

Purely for convenience:

In almost all projects: it will be the case that you will have an empty game object attached on your opening scene, for clarity let’s call it “holdAll”.

“holdAll” is persistent throughout the game.

Attached to that, you will have many files such as Shopping.js, Analytics.js, Calculations.js … etc etc

Each of those uses coroutines. So they really are best as “normal” scripts attached to an game object.

Again, it’s inevitable that almost every Unity game has an empty game object (“holdAll”) which is persistent throughout the whole game, and you use those various

I’ve never seen a Unity project that does not have that.

So, this is all great and normal. But, each time you want to use a routine from shopping.js, you need to make a local variable which, annoyingly, you have to hook to shopping.js on holdAll.

Of course, it’s much easier to just call ordinary static libraries, like when you use Mathf or the like.

Is there a solution?

Yes, here’s what I do. Make a tiny little class called say “grid”:

class grid
    {
    static var shop:Shopping;
    static var etc:Etc;
    static var etc:Etc;
 
    private static function grid()
       {
       shop = GameObject.Find("holdAll").GetComponent(Shopping);
       etc = GameObject.Find("holdAll").GetComponent(Etc);
       etc = GameObject.Find("holdAll").GetComponent(Etc);
       }
        // nb, grid() is indeed magically called (once only)
        // when one of these vars is first accessed - 
        // you need do nothing, just use the vars at will.
    }

then from anywhere at all in your project,

with no further effort,

you can just write

grid.shop.buy(..);
grid.shop.sell(..);
yield grid.shop.showDialog(...);
yield grid.shop.interactionUser(...);
x = grid.shop.count;

and so on. Same for all the others (Shopping.js, Analytics.js, Calculations.js etc etc)

I want the convenience of just being able to say

yield shop.whatever();

anywhere in the project WITHOUT needing an annoying hooked-up local variable “shopit” which leads to holdAll-Shopping.js.

But in my opinion there’s just no really good, bulletproof, way to make a static/singleton/etc, where it’s a “normal” coroutine-based Unity object.

So … for me, this seems to answer all those needs. The only downside is – effectively – one extra “.” when you type grid.shopping.

Seems to work ok ?