About 25 mins, the talk on performance improvements begins and about 27:20 he covers the new multithreaded Transform system.
The graph he uses indicates that this is in 5.6.
But there is no mention yet of this on the Roadmap?
It’s not a big feature but judging from the demo it looks like it can have a big impact in scenes with lots of NPC’s or in the demos case 20k fish.
Interesting… Looking forward on testing this.
Also wonder if the implies to transform.Translate… Being there really isn’t any difference (that I notice) at least. I use transform.Translate quite often for a lot of things. And being transform.postion can do exactly the same things (that I’ve noticed) at least.
There is a hint that there is more to come when the presenter mentions that Unity is at the brink of a performance inflection point (about 33:10 in the video).
Maybe this is the first area of Unity to receive a multithreaded boost and there is more to come…?
What Joe showed is indeed from 5.6, but the various individual optimisations aren’t great to list on the roadmap, which is why they’re missing there.
I was watching a video where the guy said by 2020 they are going to have 1000 cores by 2020, so unity better be multithreaded by then
The fish demo with C# job system and transform component performance improvements are separate things. While the first one is a big feature - the second one isn’t really a feature, so it doesn’t really belong to the roadmap.
Being able to properly scale with 20k active game objects in a scene would be awesome. Multithreaded handling of transforms would be fantastic. This improvement will definitely be welcomed.
Would love to still read about the science and wizardry behind Unity’s performance gains wherever possible, please 
That hard work done is the most valuable part of Unity for me, period
I bet a lot of it is just simple optimisations like inlining functions and such like. I think even things like the Mathf.Max function is not optimised and is far slower than a>b?a:b. Maybe they cached the transforms too.
But anyway nice to see and these things would be really handy for my current game, but as always, its like seeing a cake and not being able to eat it since I need to finish it way before Unity 5.6 will come out. 
I might be doing something completely different by then. Who knows.
Also I heard in Unity 5.6 there will be not slow down when you move static colliders. That would also be great for my current game but unfortunately I have just to create the game without colliders.
Yeah, I would love to hear all of the details as well. In the game I am currently developing, I have spent a lot of time optimizing everything to get as much scalability as possible within the current version of Unity. In space scenes with thousands of projectiles flying around, the current version of Unity still bottlenecks, though.
Here is my performance wishlist:
For Transform component optimisations: the main thing we’re doing at the moment is changing our internal architecture around Transform changes from a ‘push’ model to a ‘pull’ model.
In the past, when you set a Transform’s position/rotation, we would proactively ‘push’ that change to all the other subsystems in Unity that care about transforms: updating the bounding volume for Renderers, updating the PhysX actor, etc. This is bad for memory access patterns, bad for inlining, bad for multithreading, and potentially means doing a lot of redundant work if there are multiple things in a frame that modify transforms.
In the new model, instead of ‘pushing’ that work immediately, we just set a few dirty flags. Then, when we actually need something like the bounding boxes of renderers to be updated, we can schedule jobs that ‘pull’ all those dirty transforms, so they can do what they need to do in a tight, highly-optimised loop, across multiple threads if necessary. It’s much better for memory access, and generally much safer and easier to reason about (letting us make more optimisations) - and because we only do it when we actually need the data, you can make multiple changes to a transform beforehand without incurring extra performance cost.
Wow, I didn’t realising setting a position did so much stuff behind the scenes! You know why? Because its not in the documentation. (Which would be handy!) Maybe it would be worth adding a little bit to the documentation about performance and how to optimise use of common functions. Or is this knowledge specially designed only to be available to companies who buy the source code?
Does it also do all this stuff if you set the localPosition?
Genuine question here though is that - this kind of optimisation you stated above seems kind of obvious like the kind of thing they should have done in week 1. Well before doing things like il2cpp and all that stuff… How did they miss this for so long? Sorry if that sounds rude. Just wondering.
Well, with these new changes, it won’t need documenting anymore because it won’t be slow.
FWIW, we do have someone working on creating a series of optimisation guides, and they’re looking pretty delicious.
Yep. Any position change necessitates updating the other subsystems, it doesn’t matter which space you specified the change in.
Hmm… not to put too fine a point on it, but basically, I make it sound much easier and simpler than it actually is
Any fool can throw code at threads and call it a day… but making it efficient, deterministic, flexible, and safe, is a actually a hard problem. It’s not until quite recently that we’ve finished writing all the support we needed to do this kind of thing, and we had to learn a lot through failure along the way.
That reminds me, I need to throw more of my code at threads. Actually I don’t tend to use threads much for that very reason that you stated.
Wasn’t that what Parallel.For and all that malarky was for? So you can parallelise things without having to mess around with threads?
Is that what the job feature is going to be? Like C sharp tasks?
You could add a UnityEngine.Parallel.For to. That would be cool.
It is not quite that simple. At the current time, you can use threads with Unity but the Unity API does not allow multithreaded access, so the only things that you can do with threads at this time would be things that do not need to access the Unity API. There is a lot more to multitasking beyond simply running things in parallel. There are always concerns about the safety of the data during a multithreaded operation. For example, if multiple threads get and set the position of a GameObject’s transform at the same time, there is a chance to corrupt the data for that position.