Could Unity Running in IDE run on a separate thread?

Has Unity considered having their IDE and the running game in separate threads, then at least when I do something that locks up my game I can stop it without waiting for days for the IDE to update?

I realise this is might not be a 4.x feature but with 5.x having a job scheduling system it should be possible.

This could also have the benefit of separating the IDE and game/scene views and allowing for a much more responsive IDE?

 

I'd suggest separate process might be better isolation.

 

Either way could make writing editor extensions a bit more work, but especially separate processes as everything would have to be marshalled across process boundaries. In the first instance, thread safety would become a concern for everyone developing editor extensions and they'd have to be mindful of it. Not that it's a bad thing, but it adds complexity. All of that being said, many of the editor functions are actually multithreaded already.

 

There's a lot of problems with this, for example editor scripts, which interact with scripts in the running game. For example a custom component, controlled within the editor. The solution in Unity 5 is just to give it to the jobs manager which deals with this best it can, mostly for things like enlighten and so on.

 

I'll agree to this just because when working on a large scale project, it can take hours to open. When I worked briefly on *TDL it took like 40 minutes to open the source in unity. If the game crashed the editor, that was 40 another 40 minutes wasted! I'd lose nearly an hour and a half of work time every day from that.

*I worked on it very briefly and accomplished very little, leading to a mutual termination as my education engulfed my life.

 

Somehow I don't think it's possible without breaking a lot of the editor utility. I have to imagine there isn't any way to separate the editor from the running game or they would have done it already.

 

Seeing as how almost nothing within the Unity engine is currently thread-safe, I don't think there would be any way to be able to run the engine on a separate thread from the editor when all the components can be edited at runtime through the inspector.

 

I don't think it'd be as difficult as you think. It's just networking. The complexities of threading etc. can be hidden from the user.

 

The reality is Unity has a codebase which is monolithic. On paper it's not difficult, but there are so many complexities and gotchas with an engine that was written from the ground-up without this in mind. They're slowly moving more and more to it as time goes on, but it's certainly not as trivial as you think.

 

This would be lovely and I'd love to have it ... but I can see that this is not trivial at all - but as they are already going in that direction, maybe some day we'll get it ... I doubt this will happen before Unity 6, though, if even ever ;-)

 

I agree. If it was "easy" to let the inspector manipulate components from a separate thread, then it would be "easy" to manipulate components from a separate thread, period. But we know that they've been purposefully blocking the ability to manipulate almost everything within the engine from a separate thread since the beginning because of how un-threadsafe it all is.

 

If you say so.

Actually, it is pretty easy. (Or depending on your viewpoint, it's completely unnecessary).

-----

While there may be some gotcha's (I don't do much editor scripting) I'd want to see an example of difficulty before getting too worked up. I've done plenty of multithreaded stuff in Unity in the past, and it's been pretty straightforward.

 

You constantly repeat along the lines of it being easy(which is kind of obvious; which makes it sound condescending). We're not talking about multithreading in a Unity game.

 

Hold on a minute are you saying the the editor and the game played by the editor are the same thing?

That would make separating and making thread safe the Editor and the Engine quite an undertaking.

I assumed that the IDE or Editor and the Game were separate, just running in a 'debug' mode. So the Editor runs the Unity game engine after building the code for mono and displays the output to the game view.

But as previously stated if the editors UI 'event system' layer (or just the pause/play/stop buttons) was running on a separate thread that could interrupt the main thread then you could still have an Editor that does not lock up when the game is hogging resources.

 

Haha, yes, now I remember, there was a thread a long time ago where you kept pretending you had figured out a secret way to access components on a separate thread, and we kept asking for an example but you wouldn't give any, and just kept saying it was "easy". Well, in that case I would suggest just using the black magic you currently use to make the engine multithreaded and cast that spell at the editor window, and it should just work. Why bother Unity devs with it if you've already figured it out?

 

The Editor has far more features than just pause/play/stop though. You can view and edit all components while the game is running with the inspector; you can do nearly anything that the editor usually does while the game is actually running and modify all variables on the fly, including custom components. It isn't based on an event system, it works by using reflection to directly modify values, and it adds/edits components the same way you would do it through code in an actual game script. It's a lot like a debugger. It has to constantly reflect all values of all components in the inspector window as the game is running, so it can't be a separate process unless you built in a whole async polling layer to get or set the values of every possible .NET object, which would be an ordeal to write and a large amount of overhead while running.

 

Well I'm sorry, you're just repeating it's 'hard' which also sounds a little condescending and, kinda frankly, unenlightened. Unity does not prevent multiple threads working and Unity does not prevent multiple processes working together - this is pretty basic stuff that is done every day.

I agree, I'm magic. I mean, it's either that or you simply haven't bothered to spend a few minutes figuring out what's possible and prefer to make up fantastic scenarios to justify your inability to solve simple problems.

Hmm, so why exactly is this 'black magic' again? This sounds an awful lot like networking and serialisation to me... you know that well established computer science that has a whole forum dedicated to it?

 

And is slow. So very slow. You really don't want to include the network and serialization for debugging an app if you can avoid it. Especially a game.

 

1) How slow is slow? What are the numbers?

2) Debugging is already slow. Debugging from another process/machine is already an established concept that is often used. Example - UnityVS which runs on my *virtual machine*!

3) Luckily for us, being slow when debugging a game usually isn't a problem - in part because dev machines are usually more powerful than than the end device, in part because we're technically minded enough to work with and around and problems that arise - and the payoff is worth it.

 

Transmitting something over a network is at least an order of magnitude slower than transmitting it in thread. Sometimes many times more than that.

http://stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory
https://gist.github.com/hellerbarde/2843375

As a rough estimate, you can use the "Zip 1k with Zippy" as the time to serialize 1k worth of objects.

When multi threading there is overhead. The best time to multi thread is when the overhead is low. Splitting the IDE and the attached running Game when the IDE can do so much to the state of the running Game is the opposite of low overhead.

 

You keep on saying 'slow' I do not think it means what you think it means.

So go on then, give us some estimates. What are the costs involved (in real terms) and why is this prohibitive? How do these costs compare to the existing, and quite substantial, costs involved with debugging (both within unity and with other approaches).

For example, so far you've indicated that the time cost is '10,000ns' (which looks to actually be a compression test?). 10,000ns is *trivially* small - we are talking a hundredth of a millisecond. We'd have to be doing this test at least 100 times a frame (or serialising 100,000 items according to your logic) to have barely measurable (as in ms) impact on frame times - assuming of course this in any way impacted on game performance.

In return, Tomnnn might be able to save 40 minutes opening up Unity every time his game crashes. In perspective that's a (40min/10,000ns) 240,000,000,000% larger time cost that what you are describing as 'so very slow'.

 

Npsf - You seem to be implying that converting the entire Unity API into a standalone threadsafe networked debugging interface is both extremely simple and will have no affect on performance, and that you have the secret knowledge to make it all work, so why don't you just email the code to Unity and ask them to put it into the next patch release? Or even just make a pull request to one of their git repositories? Shouldn't take you more than an hour or two, you'd solve lots of people's problems, and you'd secure bragging rights for years to come.

 

Where do I say it'd be 'extremely simple'? You are misquoting me.

Where do I say it'd have no impact on performance? I simply disagree with the unevidenced statements that the performance concerns are prohibitive. At this time, we do not know what the performance impacts would be... but the likely possibilities range from performance increase to small, but tolerable performance loss.

Because it'd take me longer than a few hours to do, and I value my time?

 

Would it be nice? Oh yes... Yes it would.

Would it be easy to implement? Not so much.

Should they consider it for Unity5 or 6? Hell yes.

Do I see it happening? Not for a LONG time.