Oops- I was doing last-minute editing on my post before I submitted it and neglected to paste something back in. (This is why one should never edit ones posts).
It should have said:
It’s not special treatment per-se, it’s about accounting for compilation order to make sure that the routines are available for your javascript.
If you want to use xyz function from Eric’s class, it obviously has to be defined before you use it.
You can see some examples of javascript->C# interoperability with the perlin noise generator on the resource section of the unity website.
Good to know- thanks! I just made an otherwise unused folder named “Standard Assets” and now the myriad compilation errors are gone.
Well, it’s kind of special treatment…if you just make a folder called “Blah”, that won’t work.
–Eric
Hmm… I noticed that using the System.Math functions instead of the Mathf functions is already a whole lot faster (including the casting from / to double, or using double right away).
This seems to be especially the case for things like sin() or sqrt() and such.
It would be nice if Unity could, for one, implement the math functions properly for floats (what else would be the point of having Mathf in the first place?), and then provide a built in library for functions that have to run lightning fast but don’t nescessarily have to be exact.
E.g. Sin() could be implemented with a lookup table that is precised to 1/10th of a degree (I did that for my own code and the performance gain is immense, while the precision loss is not noticable in most cases).
I was quite surprised when I figured out that my code was just slow because I used rudimentary functions of Unity, like Sin() or Distance() etc. For a game engine that’s a no-no :roll:
I found this thread quite interesting as I’m a sucker for optimization.
Is there any news from Unity developers on this issue? It seems to me extremely wrong that custom made math functions should be faster than the internal Mathf functions.
Just came across this thread after profiling some code and noticing that Mathf.Abs() simply calls Math.Abs() in Unity 3.4.
Quite a revelation as in my case I was using it to try and test for denormal numbers within a heavy loop doing image processing, resulting in over 600k calls per frame. The double call nature really hammered performance.
Granted that was a specialized case, but still its something i’ll keep in mind in the future. No point calling a Mathf function if all it does is call the corresponding Math function.
Where we have two issues:
- Hail the thread necros ;), for no real reason…
- Profiling ^^. How did you profile? With Unity profiler? In either case, what shall “really hammered performance” mean? The processor simply doesn’t care about double calls as long as they are unconditionally and have no profiling code in between ;), which they probably had in your case. Additionally you were probably using the debug version, which doesn’t inline double calls…
Other than it being of vital importance to those who are unaware of the situation and have heavy usage of Unity Mathf functions, you mean? 
Along with the post above mine asking if there were any plans to address the situation, which is much better here than starting a duplicate new topic.
Granted doing a deep profile in Unity didn’t help its cause, but measuring the results (timing directly around the function) without the profiler revealed a similar situation;
No ABS in function = 80 fps
System Math.Abs = 64 fps
Unity Mathf.Abs = 54 fps
So whilst adding a call to Abs is costly regardless (to be expected), the drop of 10 fps is considerable considering you’d expect it to be the same performance as calling system Math.
Obviously this is still a somewhat special case, Abs is being called hundreds of thousands times a frame, but then its precisely these situations where it would be vital to know that calling Unity Mathf is going to slow down.
I know necroing, but this might be interesting:
Unitys Min and Max function use >= respectively <= which is a small performance decrease over > and <. When viewing in a Reflector it looks like this:
public static float Min(float a, float b)
{
return ((a >= b) ? b : a);
}
But the following which works the same is obviously slightly faster:
public static float Min(float a, float b)
{
return (a < b) ? a : b;
}
Also as Noisecrime mentioned Mathf has some functions which are a kinda pointless wrapper around some .net Math functions. Like:
public static int FloorToInt(float f)
{
return (int) Math.Floor((double) f);
}
There isn’t any performance difference between >= and >. (Or <= and <.)
–Eric
My bad, thanks for clarifying that