koobas.hobune.stream
Where does 'extern' point in UnityEngine.dll methods?
I've been poking through UnityEngine.dll with ILSpy. As a bit of background, we're seeing a huge hiccup with some downloads, and the Profiler (Deep Profile) reports the following tree:
...
WWW.get_isDone()
UnityCrossDomainHelper.GetSecurityPolicy()
...
So to try and track down what's actually going on I delved into the UnityEngine dll, but under the definition for the WWW class I see the following:
namespace UnityEngine
{
public sealed class WWW : IDisposable
{
...
public extern bool isDone
{
[WrapperlessIcall]
[MethodImpl(MethodImplOptions.InternalCall)]
get;
}
Since there's no DllImport, how can I determine where exactly this extern is pointing to? Where is isDone actually implemented?
This means that the function is already implemented in a library internal to the application. It could be in the IL (Mono in this case) or in a DLL that's already imported.
Your question of course flows to "so how do I see the code for it" but unfortunately, you can't with ILSpy. You'd have to disassemble it and read it as assembler language.
Have you asked about the hiccups you're experiencing? Maybe someone has experience with them.
Edit: Link for more info:
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx
Thanks, that mostly makes sense. Obviously I have more reading to do :)
As for the particular hiccup, our code is pretty complex (50,000 lines) and we've built things like a download manager that wraps around WWW, so I would need to create a much simpler repro before folks would be of much help. Either there's something we're we've done that's making it look like WWW.isDone is taking a looong time (1150 ms for 47 calls in one case) or there's a Unity issue that's only showing up in our case.
Nonetheless, I'll start another question and link it here.
Thanks again for the help!
if you do the 47 WWW in parallel such a thing could happen especially when you do not properly interact with it from coroutine. Reason is that each WWW object has an own worker thread in the background, so if you fire too many in parallel you cause some nagging side effects. Especially as they finish the download and load the asset, they will halt the engine (bitmap loading, asset bundle decompress, movie loading and audio loading are all blocking, syncronous calls during which nothing else will take part. 1150ms sounds liek an asset bundle with a detailed mesh for example)
Here's the full question, hopefully that gives you guys a bit more info. I'll read your comments in a few, but first, lunch :)
http://answers.unity3d.com/questions/440134/long-delay-with-wwwisdone.html
Then where the code located ,which dll ? in what language? Do you mean in C/C++? and where the dll ? regards!You'd have to disassemble it and read it as assembler language.
$$anonymous$$ost of the "extern" methods in the UnityEngine.dll belongs to native code functions which are implemented originally in C++ and usually reside directly in the player executable. So for a windows build it's simply the ".exe" file. The whole engine is actually written in C++.
Almost all classes in Unity consist of two parts: the managed part that is a .NET $$anonymous$$ono class inside the UnityEngine.dll and the actual C++ class inside the engine's core written in C++ and compiled to native code.
If you open the exe of a build made with Unity in an hex editor / viewer and search for "WWW::get_isDone" you will find it ^^. However that's only the method name inside a string table. To know where the actual code is (in binary) you would have to completely analyze and disassemble the exe.
Actually disassemble native code can be extremely difficult and even if you managed it, it's hard to deter$$anonymous$$e the purpose of the code as it's just assembly. Disassemble the native code is actually forbidden by the EULA AFAI$$anonymous$$. Though you can aquire a source code license from Unity but that costs probably $100k+.
In most cases it's not worth to think about it. A good example is this recent question. First i checked the UnityEngine.dll (ILSpy is always open ^^) just to see it's implemented externally. Then just quickly google for gamma correction and i found that article i've linked. Finally I used Debug.DrawLine to draw the graph of the method (100 sample steps) and draw it next to my own implementation(based on the article) to see if it fits.
It took me about 5 $$anonymous$$utes to figure out what the method does without ever seeing the native code.
There are some method that would be interesting to know how they are implemented, but i can live without knowing. $$anonymous$$aybe some day i come up with a solution myself. Like over here where i kind of "reverse engineered" CalculateFrustumPlanes to come up with an implementation that doesn't allocate a new Plane array each time it's called. The method is buried in a comment below my answer.
