Hello, I need faster code execution. Currently, with fixedUpdate’s time setting on the lowest, I can achieve 10,000 fixedUpdate loops per second. This is much too slow. I have looked into “Coroutines” but I believe that is now what I am looking for. Is there a way to run code faster than fixedUpdate’s capped limit. Maybe ECS?
PS. I know it can handle more speed but Unity is caping it. There is no lag and I get 450ish fps.
for (int i = 0; i < 500000; i++) or something…
What are you trying to achieve?
I believe he has code that is currently executing 10k times per second. he wants it to run faster then 10k times per second
I’m trying to get faster code execution.
You are supposed to have studied the documentation about FixedUpdate() but, just in case, it’s here: https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html
I thought I was pretty familiar with fixedUpdate, but I did have a read and found out about Application.targetFrameRate. I set that to 10000 but it does not go that high, it only reaches around 450 FPS.
Any other ideas?
Thanks for repeating the title I guess, but what they were asking is, why do you want to execute code more times per second? Because that will drastically alter what the best answer will be.
If you need something that literally executes every 0.1 milliseconds (for example, to read a hardware sensor), no amount of FixedUpdate hacking will help you. FixedUpdate isn’t actually run at the times it claims to run, but rather, on every Update, it runs X times until its own clock catches up with the ingame clock. So if “literally running every 0.1 milliseconds” is your goal, you’ll have to do something in its own thread outside Unity’s update loop entirely.
Changing the fixed timestep to such a tiny value is very very risky. If you ever add a single Rigidbody to your game, for example, such a timestep might well cripple your framerate. This is why Unity restricts it to, let’s call it “a sane value”. And as described above, it almost certainly won’t help your real problem.
So what is the actual reason you need code that executes so often?
Me? No. Maybe you should explain why you want more than 450 fps so people who understand can tell you what to do? 
What does faster mean in this context? Isn’t it many times per frame? Why is just doing a for loop not acceptable? fixedupdate is just a for loop that runs in update anyway. What are you trying to do?
My game is purely a procedural generation based software, it has no physics and only uses 1 texture in the scene and 1 raycast per loop. It is super efficient, I am only being limited by Unity. I just wanted to know if there were other ways to run code faster than fixedUpdates best.
PS. my texture refresh code is in update, so that won’t be an issue.
If you want you code being called as often as possible, why are you calling it in FixedUpdate instead of Update?
Are you trying to execute an expensive workload that is causing your framerate to drop? If not, then can you explain why executing some code more often than Update is called (so, more often than the screen can refresh) is necessary?
Mostly the thing you’re asking for (executing code more often) isn’t a conventional thing, so people here don’t know whether you’re asking for something complicated but reasonable, or whether you have a misunderstanding of some basic Unity concept that we could hopefully clear up for you. Could you describe what you’re doing with an example? Explaining why your code needs to run more often than you’d get by calling it in Update?
Okay I’ll try to be really clear.
I have an empty gameobject which shoots down a raycast and checks a pixel on a texture which is on a gameobject plane. When it hits the texture it discovers that the pixel is either RGB(255,255,255) WHITE or RGB(0,0,0) BLACK, it then says okay, change that WHITE pixel to BLACK and vise versa. Once that pixel is changed the empty gameobject which holds the raycast script moves a single pixel to the right, or left or up or down, dependant on the pattern algorithm. When I run this code in update, I am limited by the speed that update can execute code. I use fixedUpdate because I have some control over the speed at which it can run (the time menu settings (Edit->Project Settings->Time = “FixedTimestep = 0.0001” the capped lowest possible value)). Because I can change fixedUpdate’s speed of execution I use fixedUpdate. My code which refreshes the texture (planeTexture.Apply();), so the user can see the results of the algorithm, lives in update; because if it were to live in fixedUpdate it would cause major lag as it would be refreshing the texture faster than the FPS, which also would be pointless as the FPS does not need to display over 60.
I wish to generate the pattern faster than I currently am, which is much too slow.
So do more than one pixel at a time?
the next pixels rely on the previous. It has to be sequential.
Why not loop N times per update?
Something like this (naive pseudo code):
public class UpdateAlotScript : MonoBehaviour
{
public const int UpdatesPerSecond = 1000000;
void Update()
{
int cnt = UpdatesPerSecond * Time.deltaTime;
//may want to cap 'cnt' at some amount here based on framerate
for(int i = 0; i < cnt; i++)
{
DoWork();
}
}
void DoWork()
{
//the logic you expect to have occur N times per second
}
}
I mean this will effectively give you the same effect of using FixedUpdate since as StarManta pointed out… FixedUpdate is really ran every Update the number of times necessary to catch up.
MIND YOU that this code does not account for very large values. Due to the time that it takes to perform your work could effectively get larger than the amount of time necessary, ‘cnt’ could start growing so large you get a run away effect where each frame takes longer and longer to calculate. Usually you cap this at some amount so as to avoid run away. For example if you’re targeting 60 fps, you should max ‘cnt’ to be ‘0.0166666f * UpdatesPerSecond’.
Okay, yup, answer, thank you, kind sir. I guess I had a mental block thinking fixedUpdate needed to run to completion so unity could do all their internal stuff so that the raycast would be able to see the next pixel. But now I’ve learned that just manipulating a texture can happen within a loop and does not rely on unity to update it elsewhere.
I had this code and just adding the for loop around the logic (where the algorithm computes) made it doubly as fast.
fTimeLeft -= Time.deltaTime;
if (fTimeLeft < 0)
{
for (int i = 0; i < 2; i++)
{
Logic();
++a;
}
Perhaps this is a silly thought, but anyway:
From your description user interaction seems purely coincidal, and only for viewing purpose. Perhaps you can separate the two. Have a worker thread that goes full tilt building the texture, and every so often (maybe once a second) copy the result over for the viewer to see. The worker thread doesn’t have to be tied to any of Unity’s rendering shenenigans.
-ch
Why use a raycast ant not just sample by the position?