27 replies to this topic

[ElvishJerricco]

LeDark Lua, on 09 August 2015 - 07:04 AM, said:

On emulators I get 62FPS on MC 15/20-30

Minecraft has two main components. The renderer and the world. The world calculates all the things that need to be happening in the world logically. This includes things like a furnace updating its progress, a quarry breaking some blocks, or redstone updates. The world operates at 20 ticks per second (ideally). So 20 times a second, all of these things are updated.

The renderer operates at either a capped max FPS, or however fast it is capable of rendering. Ideally this is something like 60fps. In CC emulators, this is represented by the drawing of the CC screen. All this is doing is drawing everything in the world based on current world information. Ideally, you'd like this to be around 60fps, but lower end computers won't have the graphics power for this. But all the fps relates to is how fast it is capable of drawing things on screen. It isn't bound by the ticks per second.

ComputerCraft has its own component, the Lua VM, which runs all the computers' code. This is not bound by either of the other two components. It is its own thread that runs Lua code as fast as it is capable of (with limitations set by dan, but this is negligible). Lua code is in no way related to the other two components. It will run on its own, as fast as it can. The exception is code that involves pulling events. If I remember correctly, you can pull at most one event per world tick. This can possibly limit you to 20 iterations of a loop per second, but it's very rare that you need to be pulling so many events. Things that would cause event pulling are: rednet communication, some (but not many) peripheral method calls, accepting user input, etc..

So basically, the things that you think are limiting your Lua code aren't limiting it at all unless you are being irresponsible with the kind of code you're running in large loop. The only real limitation is the performance of your computer, as you've mentioned. But I promise you, any computer built in the last 20 years is capable of running a simple for loop in lua at a few million times a second. The limitation is entirely just the kind of code you're wanting to run in that loop. But unless you're calling event pulling code, that won't even be a noticeable limitation. Not to mention, if that's the source of limitation, loadstring won't help, as it will just call the same code, causing the same limitation.

Finally, you should always remember this Donald Knuth quote

Quote

Premature optimization is the root of all evil.

Always begin with naive implementations and see where performance problems arise from there. Your life will be miles easier and you'll avoid trying to do weird hacks like this that are entirely unnecessary.

[MKlegoman357]

ElvishJerricco, on 09 August 2015 - 08:42 AM, said:

The exception is code that involves pulling events. If I remember correctly, you can pull at most one event per world tick. This can possibly limit you to 20 iterations of a loop per second, but it's very rare that you need to be pulling so many events. Things that would cause event pulling are: rednet communication, some (but not many) peripheral method calls, accepting user input, etc..

Nope. CC can process events as fast as it can process, for example, a for loop. Limitations are 256 events at most in the event queue. But some events do actually depend on ticks, like 'timer'.

[Bomb Bloke]

MKlegoman357, on 09 August 2015 - 09:26 AM, said:

But some events do actually depend on ticks, like 'timer'.

And to be absolutely clear: Even pulling timer events is "instant". It's simply the case that it takes a minimum of a server tick for them to appear in the event queue after calling os.startTimer(). Some other event types have a similar delay on their "generation" - but rednet/key/char events aren't among them. "Delayed" events are exceptions, not the rule, and can all be pulled about the moment they make it to the queue.

The one catch is that pulling an event involves yielding, and the system won't be resumed until any other systems running on the server that are able to be resumed have executed their next chunk of code and yielded again. The time that takes is still unrelated to the server tick rate, of course (ditto for your frame rate), and even under a decent load you'd still expect each yield to be resumed well within a server tick.

[LeDark Lua]

Ok thanks But then theres a bad thing when I update bunch of code in a lopp and it frezzes all of the other texts...

[ElvishJerricco]

LeDark Lua, on 09 August 2015 - 01:37 PM, said:

Ok thanks But then theres a bad thing when I update bunch of code in a lopp and it frezzes all of the other texts...

That sounds like you're just trying to do way more than is likely needed in a loop. To help any further, we'd have to see your code in full.

[LeDark Lua]

I have functions like so:

funcTable={}

function updatePrint()
   ---a lot of code here, about 100 lines
   print(result)
end

funcTable[1]=updatePrint

function updatePrints()
   for i=1, #funcTable do
      funcTable[i].updatePrint()
   end
end

updatePrints()

So now until the loops index 1 will finnish 100line code it will take long and thats my problem. I want to update the code instantly. So that there would be slight of an delay not a long delay.

[Bomb Bloke]

In full, please. I suggest a pastebin link.

[flaghacker]

LeDark Lua, on 10 August 2015 - 12:26 PM, said:

I have functions like so:

funcTable={}

function updatePrint()
   ---a lot of code here, about 100 lines
   print(result)
end

funcTable[1]=updatePrint

function updatePrints()
   for i=1, #funcTable do
      funcTable[i].updatePrint()
   end
end

updatePrints()

So now until the loops index 1 will finnish 100line code it will take long and thats my problem. I want to update the code instantly. So that there would be slight of an delay not a long delay.

This line:

funcTable[i].updatePrint()

should be

funcTable[i]()

because the function "updatePrint" gets copied to "1", not to "1.updatePrint".

I suggest you to show us the full code anyway, as that feels like a horrible way to accomplish anything, and maybe we can give you some tips.