Accessing components seems slow

[Jrius]

Hello again,

I've noticed functions returning components are surprisingly slow: GetComponent<>(), GetTransform() and AddComponent<>() seem to take significantly more time in C++ than they do in C#.

I've benchmarked with those two scripts:
C#:

int numObjsToInstantiate = 2500;
GameObject go;
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i=0; i<numObjsToInstantiate; i++)
{
    go = new GameObject();
    go.GetComponent<Transform>().parent = transform;
    go.AddComponent<MeshFilter>();
    go.AddComponent<MeshRenderer>();
}
sw.Stop();
print("Elapsed time: " + sw.ElapsedMilliseconds);

C++

int numObjsToInstantiate = 2500;
std::clock_t start = std::clock();
for (int i = 0; i<numObjsToInstantiate; i++)
{
    GameObject go;
    go.GetComponent<Transform>().SetParent(GetTransform());
    go.AddComponent<MeshFilter>();
    go.AddComponent<MeshRenderer>();
}
float diff = (std::clock() - start) / (double)(CLOCKS_PER_SEC / 1000);
char buf[256];
sprintf(buf, "Elapsed time: %d ms", (int)diff);
Debug::Log(String(buf));

The C# script runs in roughly 30 milliseconds. The C++ one takes 20 seconds.

I'm using Unity as a scene viewer for data from an old game, meaning I'm building the whole scene in Start() and adding a few hundred/thousands of components, setting parents for transforms, etc. In my case it's no big deal since it only runs once, but I thought the difference was a bit strange.

(I had no performance issue with other parts of the Unity API. I'm even able to load hundreds of textures in less than a second, which is a real delight.)

[jacksondunstan]

Hi @Jrius , sorry to hear you're having performance issues. Thanks for providing examples. I pasted them into my own copy of the project and got the following results:

Language	Time
C#	24
C++	215

That's indeed quite a slowdown in C++, but nowhere near going from 30ms to 20,000ms. There is overhead involved when calling into C# and this code does that exclusively, so it's a sort of "worst case scenario." FWIW, pulling the GetTransform() call out of the loop reduced the C++ time to 171ms.

Regardless, you're experiencing much worse performance than I am and we should try to figure out why. The code you provided actually didn't compile in my copy of the project on two lines:

go.GetComponent<Transform>().SetParent(GetTransform());

Debug::Log(String(buf));

The reason is the same on both lines, but I'll use Debug::Log as an example. It takes a System::Object& parameter which the String(buf) expression can't bind to since you can't take a reference to an r-value. The solution is simple: create a local variable and pass that instead.

String msg = String(buf);
Debug::Log(msg);

The way you wrote it used to work because reference parameters weren't used, but there was a change to the code generator on November 19 that introduced references as a performance improvement. Is it possible you're using a version of the project that's from before November 20?

BTW, it's cool to hear about your use case of adapting an old game to Unity as a new viewer. I didn't have that in mind when I started this project, so it's fun to see the creative ways people end up using it. :)

[Jrius]

Ah, I'm beginning to understand what the issue is.

Since I'm accessing a lot of managed objects during a single frame, the ObjectStore was registering a lot of object handles until it hit the default limit of 1000.
I came across your blog post about object handles, and noticed at the time you were using a default value of 100,000, so I increased DefaultMaxSimultaneous in the JSON to 100,000. This solved my problems, although it might have been a bit overkill.

However, it seems increasing the limit is what causes these slowdowns. In a new, empty project the code I posted executes in ~200 milliseconds for a limit of 1000, but with a limit of 100,000 it takes roughly 20,000 ms.

I'm still not really sure why it slows down these particular methods while the rest of the API is fine, but at least that's a start. I'll continue investigating tomorrow.

Also, I just updated my copy of the project to the latest version (I originally downloaded the project in February, IIRC). Strangely enough Visual Studio still accepts taking the reference of an rvalue - which indeed sounds like bad practice now that I think about it... I'll watch out for it in the future.

[Jrius]

Okay, I made more progress on the issue.

I was wondering why I needed all those 100,000 handles while I definitely wasn't using that much simultaneously, and ran a few tests.
It seems the culprit is System::String, which does not release its handle once it goes out of scope and is destroyed.
For instance, I ran the following with as few as 100 handles (enough to make sure my plugin would run, too few for more than 100 simultaneous managed objects):

void funcA() {
    for (int i=0; i<5000, i++)
        GameObject obj;
}

void funcB() {
    for (int i=0; i<5000, i++)
        String someString("some string");
}

// call either funcA or funcB depending of the required test

funcA runs without issue. funcB results in a lack of available handles.

My importer names all objects, materials and textures, hence creating a lot of strings. I removed all the object naming, and since I'm not creating strings anymore, I can import my whole scene in under a second and with only 100 handles. Yeah ! Well, now all my objects are unnamed, but I can live without it for now.

[jacksondunstan]

Thanks so much for digging into this so deeply! With your findings, the fix was trivial to implement. String objects created from string literals weren't being ref-counted, so I added one line to do that and the test code now works. 🎉

Here's the commit that fixes the issue: 4af0351

Please let me know if you run into any other issues and have fun creating your viewer. 👍

[Jrius]

That did the trick ! Thanks for the fix.