Brace yourselves folks:
That’s right, calling DateTime.Now takes 2275ms on an iPhone X in WebGL!
I reported this as a bug.
Curious what you get if you expand that. Often I find that some operation takes a surprising amount of time, only to expand it and find that is merely triggered a GC collect. So, not the fault of the operation itself.
It didn’t trigger a GC collect. WebGL’s runtime on memory-constrained platforms / mobile browsers probably defers initializing the culture crap in mscorlib.
Also, it can’t expand because there’s no remote Deep Profiling, and probably never will be for WebGL, so I manually wrapped my Profiler calls like the docs said and was in utter disbelief that the delay was in the last place I would look.
Interesting. Well, as a workaround, can you just call DateTime.Now once near the start of the game until this is hopefully fixed? Or so you see this delay every time you call it?
I just switched to using Time.time. It was third party code that didn’t really need to use DateTime.Now at all.
I think yes, for people who need this functionality, otherwise, they should put DateTime.Now in an Awake. Now that there is multithreading in WebGL WASM (not that I’ve tested it, and doubtful it’s even shipping on iOS), I’d probably call DateTime.Now in a thread once and replace DateTime.Now in runtime thread code with some kind of async call.