Improve JSON Deserialization Performance

[robertlong]

Currently JSON deserialization is a bit slow and not concurrent. It blocks the renderer and causes dropped frames. I'd like to move it to another thread or at least make it concurrent. There's also likely a lot of room for improvement in overall parsing speed.

[stevenvergenz]

I noticed that buffer data gets copied to the buffer view objects, which get copied to the accessor objects. All the copying seems wasteful, wouldn't it make more sense to provide access to the original buffer via a function that maps the index space? So in lieu of bytes[] GLTFBuffer.Data, you might have bytes[] GLTFBuffer.GetBytes(int offset, int byteLength), and have GLTFBufferView implement the same interface. That way you don't have to copy anything until it's converted to its final type in the accessor.

[robertlong]

Performance greatly improved via manual deserialization in db40b19

Previously we were using JSON.NET's JsonConvert.DeserializeObject which uses reflection to deserialize the provided object.

I've moved everything to manual deserialization which removes all reflection and really speeds things up.

Sample Model	Reflection Parse Time	Reflection GCAlloc	Manual Parse Time	Manual GCAlloc
Lantern	389.40ms	7.6MB	31.56ms	99.6KB
Corset	377.99ms	7.8MB	29.36ms	55.7KB
BoomBox	384.86ms	7.8MB	29.29ms	85KB

There's probably still a lot more room for performance improvements, but I'm feeling pretty good about our parsing performance now.

[stevenvergenz]

Wow, that's some intense savings. Nicely done!

[donmccurdy]

Any idea why parsing here would be slower than JSON parsing in e.g. the browser? All three of the sample models above take ~3ms with JSON.parse() in Firefox, or 10x faster.. I suppose that's partly because the C# is processing the model into structured objects and typed values, whereas JS is looser about this? I'm testing on a different machine here of course, but it's a fairly old laptop so I'd be surprised if that's the difference.