Performance trouble and variable content between VS C# Native project and Unity's project

Hello guys,
I'm currently working with an external open source project (xBim Essentials) that I try to integrate into unity.
I can use their dll but due to some issue I prefer to use directly the native code (easier to debug with it etc...).

Just to precise my working environment :
- Unity 2017.4.8f1 & .NET 4.6 & VS2017 & Windows10 (I used this previously)
- Unity 2018.2.0f2 & .NET 4.6 & VS2017 & Windows10 (I'm currently using this one)

But when I try to execute it in Unity, there is some unexpected behaviour maybe due to difference between unity compiler and vs compiler so I come here to maybe have more information in those behaviour.

Their main logic is to use a MemoryModel to load the "smallest" files ( < 100Mb ) and they switch to ESENT database model when the file size exceeds 100Mb.

1) When I execute this code :

Code (CSharp):

1. var labelIndexDef = string.Format("+{0}\0{1}\0{2}\0\0", colNameIfcType, colNameSecondaryKey, colNameEntityLabel);

If I'm in their VS Native project the labelIndexDef variable contains this "+IfcType\0SecondaryKey\0EntityLabel\0\0" with a size of 35 char.

But in Unity the debugger indicates something slightly different but I don't know why... Could it be due to the Unity' compiler ?
"+IfcType" with a size of 35 char.


I can see a difference in string type but System.String and string are the same in C# language except if I miss something but I don't think .
Could it be due to some "Marshalling" problems?

2) When I execute the same code in both environment the execution time is different for a file that could be open in 1sec in the native C# VS project it takes 1-2sec whereas in Unity it takes 2-3sec.
And this is only for a 3Mb file. This one is generated by using the "MemoryModel" logic

When I try this on a 100Mb file the time is 10-20sec for the native one but 1h in Unity with the same source code so this one will use the ESENT model.

I start to check from a compiler side if something could generate this huge processing time difference :/

All their logic is based on Reflection and LINQ when they try to generate the models and manipulate the datas.

Thanks in advance for any help that could be provided by anyone !

Aurelien.

 

Something that sticks out is that the string is cut at \0, which is the null character.

The behaviour around that character is strange in general. You can see exactly the same behaviour in a plain Unity script:

Code (csharp):

1. void Start() {
2.     var text = "a\0b";
3.     Debug.Log(text); //prints "a"
4.     Debug.Log(text.Length); // prints 3
5.     GetComponent<Text>().text = text; // sets the text component to "a"
6. }

I always assumed this was a C# quirk, but if you're not getting it in Visual Studio, it might not be? Note that I'm using the incremental compiler for the test, which is Roslyn-based, so it shouldn't be a Mono thing.

No idea about the slowness!

 

@Baste thanks for the answer even if it's a short one
I'm starting to tilt on this issue cause I'm on it for a week now...

I totally dislike this '\0' separator logic cause for me it could just cause some unexpected behaviour but it's a microsoft choice sadly...

This is defienitly a C# quirk cause as you said : string.Lenth = complete string size with '\0'
Displaying string display it until the first '\0' encountered
But split the string based on '\0' will display each element after the first '\0'...

My main concern or problem with this '\0' and string display in VS Debugger is the fact VS with unity can't display it whereas VS pure can. So I can't be sure of what could happen after this. I think, the code behind will use the string entirely and get rid of the '\0' display in debbuger as it must be but I can't be sure for now cause it doesn't work in Unity environment.

Slowness is a trouble but I will take a look later on this cause the non-working problem is my main one for now.

 

Since it's not a compiler thing, it's probably a runtime thing - the default .NET runtime you get when VS is running sanitises strings in a way that Unity's semi-custom Mono runtime doesn't. This might be undefined behaviour, it might be a Unity bug, and it might be a Mono bug.

@JoshPeterson, any insight? Seems like your area of expertise (and an interesting issue!)

 

Indeed if @JoshPeterson can bring me some lights on this, you are welcomed!

 

Thanks for your answer @mkderoy !
Ok I think I will not be able to fill this before monday sadly.

So for you it could be just something bad in the debugger ?
Cause for me it was probably deeper than this and this could affect the runtime part of our project.

I think I will have to setup a small project to repro this within unity and within a native VS project ?

If you wanna take a look on a performance side too, fill free to do it. Cause for me, there is a performance issue trouble too but I can't figure out why.
Maybe I will create 2 bug ticket one for the "\0" and one for the huge performance issue.

 

I submit the first issue concerning the "\0" right now, here is the ticket : Case 1072468
And the fogbuz associated : https://fogbugz.unity3d.com/default.asp?1072468_p48tu4se7f91ved0

I forget to mention it in the ticket but it happens on Unity 2017.4 (due to LTS I didn't test earlier versions) / 2018.1 / 2018.2
And I use : Visual Studio 2017 + VSTU updated

 

@JoshPeterson or @mkderoy the fogbugz right above is validated by your QA Team.
Would it be possible to keep me in touch if it's something that could altered the code logic during runtime or if it's just something visual that just affect the readability in debugger / debug.Log / etc...
Due to the fact my code have some weird behaviour when I reach the lines with that kind of string, I'm worried