loadstring has problems with tables...

Well, the problem here is you're giving it a table pointer, not the table. tostring( value ) is giving you an address (table: 0x5dfe8 or similar), and the later loadstring is, of course, going to error saying "hey, I didn't expect random numbers and letters like that".

Try running this normally, and you'll see the similarities in the error:

thing = table: 0x5dfe8 

Soo how to fix it?

Normally, I'd say use textutils.serialize to get the string code to replicate the table. In this case, I'll ask: what are you trying to do. Because what you're doing is almost entirely useless.

Well I'm trying to make an some sort of API that updates all of the table functions at once.
Well better instance update code.

Using loadstring like this is a really dirty hack that I'd avoid at all costs. Never, EVER use loadstring except for the purpose of loading arbitrary code. Don't try to build functions like that when you can just actually build a function. What exactly are you trying to do, so that we can help you find a more appropriate solution?

I want to run code at once. I have a table where I store my objects and every object has an update function that needs to be updated. So how to update thoose functions without looping trough the table?

Unless those functions are assigned to different variables you'll need a loop, but I don't really ser why that's bad to you. Why cannot you use a loop?

objects are assigned from 1-Infinity

So if I have 100 object and I update them in a loop, 20fps is the max so it will finnish the full update in 5full frames I suppose.

Ehm, textutils.serialize does not support functons and another tables :/

LeDark Lua, on 07 August 2015 - 08:55 AM said:

objects are assigned from 1-Infinity

So if I have 100 object and I update them in a loop, 20fps is the max so it will finnish the full update in 5full frames I suppose.

Where did you get that number? Loops will work as fast as your computer can handle, meaning a few million iterations per second with small loops.

It depends on the VM like java is make in some language and lua is made in java soo there is a delay and the lua depends on java which depends on the lsnguage java is made in.

LeDark Lua, on 08 August 2015 - 04:18 PM said:

It depends on the VM like java is make in some language and lua is made in java soo there is a delay and the lua depends on java which depends on the lsnguage java is made in.

The Java VM that your computer will use JITs the Java bytecode. This means it gets translated into machine code - what your CPU actually runs. Whilst Java is still slower than writing in machine code, the overhead is still significantly smaller than you make out.

The Lua VM however is interpreted. I've experimented with compiling to Java bytcode (which then gets converted to machine code) and it works mostly, have a read about performance differences but in the end it only amounts to about 2-5x performance increase.

However, despite Lua is massively slower than machine code, it isn't as slow as 20Hz (20 instructions per second). You are probably getting confused with the Minecraft update speed - which is 20Hz. Some actions - such as sleep(0) and some peripheral calls are 'synchronised' with the server tick - and so stop your code running until the next server tick.

TLDR Use loops, this 20fps stuff is nonsense.

but what if I have a low end pc. that's why I need performance ;)/>

LeDark Lua, on 08 August 2015 - 05:25 PM said:

but what if I have a low end pc. that's why I need performance ;)/>

If your PC seriously lags from lua code, you've bought your computer from the wrong person.

It doesn't lag it jus doesn't like big performance.

LeDark Lua, on 09 August 2015 - 06:29 AM said:

It doesn't lag it jus doesn't like big performance.

If you have a graphics card and CPU made in the last 5 years, it should be able to run MC at 30 FPS (MINIMUM), and executing Lua code (especially through CC) shouldn't have any impact.
(Note that using a lot of mods can impact FPS, even with a good PC)

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

If you're talking about your MineCraft framerate, that's also unrelated to the number of loop iterations ComputerCraft can complete in a second.

If you want proof, just run this code:

for i = 1, 100000 do end

It will run almost instantly.

LeDark Lua, on 09 August 2015 - 08: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

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.

ElvishJerricco, on 09 August 2015 - 09: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'.

MKlegoman357, on 09 August 2015 - 10: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.

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…

LeDark Lua, on 09 August 2015 - 02: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.

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.

In full, please. I suggest a pastebin link.

LeDark Lua, on 10 August 2015 - 01: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.