koobas.hobune.stream
How can use C# to make a loop run at maximum speed without stalling game time?
I'm a beginner using C#. This question is built on the first question I asked on unity answers. This is because though I had success in preventing my simulation from freezing on play, the previous solution was very slow. I am having trouble grasping how to integrate these standard functions that run every frame, with lengthy computational tasks which ideally disregard the advancement of frames until compete.
I should also point out that it is only when I do a pair of nested loops that this becomes intolerably slow using the way that I know how to do this.
I'm fairly new to Unity so this might not be possible but look into threading. Most systems (even mobile devices) are multicore these days. Pushing the work onto a second core via a second thread will give you max CPU through put without hindering the primary/display thread. If your second thread runs too long, you'll be stuck waiting for it however so be careful - threading can be deceptively tricky if you're not experienced with it.
Seems I cannot post twice to the same question, so I'll edit this old answer.
Are you allocating memory between each frame? Memory allocation can be rather expensive, especially if you're fragmenting system memory and the GC is constantly reorganizing memory behind your back.
Over-use of loops every frame can easily cause slowdown. Co-routines perform actions spread over multiple frames which allow for the same loops to occur but not all at once, which is fine in most situations. Check out:
http://docs.unity3d.com/Documentation/ScriptReference/index.Coroutines_26_Yield.html
Before I had a co-routine in place it actually caused halt; You press the play button and the arrow icon on the button turns not blue, but black and the button appears to stay down. The console shows no updates.
Now she runs but I've never been able to sit through the full process. I am attempting to execute some 106000 individual print statements, 1 loop at a time and thus far I have had the patience to let it go until roughly the 3500th. Also it seems to slow down as it goes. $$anonymous$$aybe this means there is some sort of garbage building up?
So are we saying then that as the programmer I specify how many loops to do each frame then? Forcing me to find an optimum number of loop cycles per frame for speed?
Print statements cause $$anonymous$$ASSIVE slowdown. Using the $$anonymous$$onodevelop debugger is better but even at that there is still going to be major slowdown with that much output.
With coroutines you can limit how many times (per frame) the loop should run, that way you space it out over several frames. Coroutines are useful in this respect, allowing for large tasks to be completed over time and thus not causing the lag you are experiencing by preventing the need to complete the work all at once.
"print" (or Debug.Log which is called inside print) Is very slow in the editor. It's only ment for debugging purposes. However when you create a standalone build it runs much faster. The result can be viewed in the output_log.txt.
It's not really clear what you actually want to do, so we can't suggest solutions if we don't know what you're actually doing / you want to achieve.
In general if you do pure computing in your for loops which doesn't involve the Unity API you can use a seperate threads for it, just keep in mind that you have to synchronise them when you're done.
Well What I actually wanted to do does not involve debug logs! So this is excellent news. I merely wanted to know that I could build the right flow before I put the business end code in. But if I'm hearing what you are saying correctly, I should just dive in and perhaps include the odd debug log so that I know it went through the motions in the right order, as opposed to forcing a massive print list.
I like what you are saying about using a separate thread. But are you saying that if I don't include certain unity API features it will AUTO$$anonymous$$ATICALLY make a new thread? Because I wouldn't know how to specify that if it needs be.
Also when you say I have to synchronize them when I'm done- I hope that just implies a temporary performance ding, and not something else I need to learn to code haha.
I changed my code so that ins$$anonymous$$d of on every loop cycle, the print statement fires every 100 of them. There is a noted increase in speed however it is still unusable. In addition, the progress actually slows with every subsequent cycle and this problem is common to both versions. Any thoughts on this?
Without a clearer picture we can only guess at what your problem might be. Do you have Pro? If so, run your program in the profiler and see what is eating up all the time. Also take a look at stats. Are you using more memory each cycle? Is the amount of geometry increasing?
There is no geometry yet. Why put real function into the program if it can't simply cycle through a road map which is ideally instantaneous in under 20 $$anonymous$$utes. If it helps my end goal is to perform a digitization of sort on a terrain geometry. Im going to shoot rays down at the terrain in a matrix, effectively 3d scanning it. You can see now at least why I'd want an x and a y loop. Perhaps there's a simpler path of scanning than nested loops? Oh ya.. no Pro just free version. I don't want to wake up the trial just for this either.
