why this code runs faster ???

[startup]

first code

my_table = {}
for i = 1,300 do
num = Math.Random(111111111, 999999999);
Table.Insert(my_table, i, num);
end
Concated = Table.Concat(my_table, "_", 1, TABLE_ALL);
Dialog.Message("Notice", Concated, MB_OK, MB_ICONINFORMATION, MB_DEFBUTTON1); 

run very slow

second code

my_table = {}
for i = 1,300 do
num = Math.Random(111111111, 999999999);
Table.Insert(my_table, i, num);
end
Concated = Table.Concat(my_table, " _ ", 1, TABLE_ALL);
Dialog.Message("Notice", Concated, MB_OK, MB_ICONINFORMATION, MB_DEFBUTTON1); 

runs very fast

the deference is in line 5
in the table.concat function

when i concat with " _ " the code runs very fast

when i concat with "_" the code runs so slow

i need to Concat with "_"
can i know why slow ??
is there a solution ??

[Shrek]

Try it with pure Lua:

my_table [COLOR="#FF0000"]=[/COLOR] [COLOR="#FF0000"]{}[/COLOR]

[COLOR="#0000FF"]for[/COLOR] i [COLOR="#FF0000"]=[/COLOR] [COLOR="#000000"]1[/COLOR][COLOR="#FF0000"],[/COLOR][COLOR="#000000"]300[/COLOR] [COLOR="#0000FF"]do[/COLOR]
 [COLOR="#0000FF"]table.insert[/COLOR](my_table[COLOR="#FF0000"],[/COLOR][COLOR="#0000FF"]math.random[/COLOR]([COLOR="#000000"]111111111[/COLOR][COLOR="#FF0000"],[/COLOR][COLOR="#000000"]999999999[/COLOR]))
[COLOR="#0000FF"]end[/COLOR]

Dialog[COLOR="#FF0000"].[/COLOR]Message([COLOR="#800080"]"Notice"[/COLOR][COLOR="#FF0000"],[/COLOR][COLOR="#0000FF"]table.concat[/COLOR](my_table[COLOR="#FF0000"],[/COLOR][COLOR="#800080"]"_"[/COLOR]))

[startup]

shrek
i make a try to your code
but also pure lua did not make any diffrence
thanks shrek for trying help


any one know why ??

concat function too slow when i put 1 char
then become so fast when adding another char to it ??
so strange

any explanation ??

[startup]

thanks shrek
thanks all
problem resolved :yes

[Imagine Programming]

thanks shrek
thanks all
problem resolved :yes

Care to share how you solved it?

[startup]

Care to share how you solved it?

ok
let step back

when i concat with " _ " the code runs very fast

when i concat with "_" the code runs so slow
[/FONT][/SIZE]

i was totally wrong here
the slow was in displaying the message

i put the message for debugging purpose
so i detect finally that is no difference between concat with " _ " or concat with "_"
both are fast
no need for dialog message that consume time
simply i remove the dialog message line :yes

[startup]

to make sure display the result (Concated) in an input instate of the dialog message
you will know that is no difference

[Imagine Programming]

If you want to debug faster, I would suggest the Debug dialog (even though that can be extremely slow too if you send data to the debug dialog as well). (Debug.ShowWindow(true) and Debug.Print(str)).

Another way is to debug to a file (untested):

local log = io.open("logfile.log", "wb");
if(log)then
    -- loop here
    my_table = {}
    for i = 1,300 do
        num = Math.Random(111111111, 999999999);
        Table.Insert(my_table, i, num);
    end
    Concatenated = Table.Concat(my_table, "_", 1, TABLE_ALL); 
    
    -- log result
    log:write(Concatenated.."\r\n");
end

[startup]

thanks Imagine Programming for advice :yes

notice
all what i care was my program speed (in the concat function)
so
i use an input for that (input.settext)
after that i feel so comfortable about the program speed

i simply delete the input from my project


no problem if the dialog or /Debug message was slow
no need for them

thanks again :yes

[EnGuardian]

If you need to process something that dont need to be fully globaly available, then use local variables for that, because its much faster then global (and global variables is default in LUA, in all other languages local variables is as default).

For Debug im using Debug.ShowWindow and Debug.SetTraceMode, looks OK. You can also use something like Paragraph/Input/etc. Text thing like Status Bar, it will be OK too, but using new Windows to get some information is very slow, even you set AMS to work for max. speed (everything will be preloaded into a RAM, and ready to use), its not working for first time, first time when you call that windows, you need to wait application to create it in RAM, and its around 1-2 second, after that is created, same window with different text will be open in 0 second, because its ready to use from RAM.
You can test it with Dialog.FileBrowse and Dialog.FolderBrowse, because there is delay 2 seconds. Make in AMS 1 button with Dialog.FileBrowse/Dialog.FolderBrowse. Run applicatin, click the button, you will figure out that window needs 2-3 seconds to open. Close it, and press again button, there it is, you will open that window in 0 second.

[Imagine Programming]

EnGuardian - 2 seconds? Really? I see the Dialogs instantly.

The best way to debug really fast with graphical feedback is to use a console btw. Use Windows API to allocate a console and print your information to that console. Otherwise generate a logfile using the Lua's io functions, not with the AMS TextFile functions.

[EnGuardian]

I said 2 seconds as example, the point is, 1st time (when you start application), there is delay (always, on every PC, 100%), then for any another time (when you going to do second time the same job), its instantly. If you do some RAM cleaning/optimizing/etc. stupid things, then click the button, you will figure out there will be more delay, and highly chance that skin/style will not appear on new window (new window will be without a custom skin, or even without default OS skin).
Im working around on 2xSSDs, OCZ and Intel, and 1x WD Black, so if there is delay more then 0.1MS, its slow for me, so i can notice it when its not instantly, even if you are talking about RAM, but even if you are on slow HDD, slow RAM, or even on RAM Disk and some servers HDDs, etc., you can notice the same thing in the same way for sure, you can test it. Another example, make 1x main window (with button to open DialogEx), and 1x dialogex with some random text, buttons, images, etc. Now, start your application. Press button to open dialogex window, and concentrate your mind/eyes on that delay, how much time it need to show you a another window. You will see, there is delay as always on 1st time, first, there will be delay for creation, after a creation, your new window will become empty, without a color and anything on it, it usualy takes very low delay that can be easy sow on older computers (but the new machines have the same thing), then, your window will be shown propertly. Now, close that dialogex, and press button again, you will see, this time, it will be instantly, in a speed of a light, like thunter, boom, in 0MS, there will be everything shown, and every next time you press the same button to do the same job, it will be instantly, until you close the application and start it again, then you will have the same thing, 1st time with delay, every next time instant. The most delay record going to the file/folder browse.

[EnGuardian]

The same problem delay have LUA with global variables, not because local variables is faster because limits, so global variables is slow for active working, but when you creating a variable, there is a delay, and thats why code is faster if you type first variable = {}; (that means you created that variable as empty, it took a space in RAM, and that is much faster then creating new variable with fully informations), then you do variable = something else + code to work out with that variable (now, its much faster to edit existing variable in RAM, if its local, it will be more faster in editing).
For cheap things like buttons, paragraphs, etc., it will be still fast, and not a big problem (AMS have that delay, but i think its a RAM configuration (Memory Management (Automatic/Maximize Speed/Conserve Memory; all that options is = Conserve Memory)) bug in AMS, not by LUA), or for some low processes, additional speed is not needed, but for some generators or higher work out processes, additional speed of ~60% only based on LUA code is a good way to get almost double speed up for longer progresses, or if you running LUA with CUDA, that percentage is way too higher and way too fast.

[Imagine Programming]

The time it lasts longer the first time differs about 50ms - 100ms, a user on a modern system will not even notice it. So not on every PC, always.

Also, when you declare a variable which holds an empty table, an empty table will be created in memory. Each time when you add a variable to that table, it will have to re-allocate the memory required, allocate memory for a new variable, assign this to the array or hash index for a Lua table and store everything in memory.

So for a table value, it doesn't really matter, considering each key / item in the table will have to be initialized just like any other variable. Don't forget that all variables (local or global) will just be keys inside a table object. The local variables in Lua 5.1 will reside in the function environment (which is a table) and the global variables will reside in _G (which is also a table). Local variables will always be slightly faster than global variables due to the check for variables in the scopes up to the global scope, but the use of global variables is not recommended at all in Lua.

Keeping that in mind, I've written a lot of Lua code in my life and I can tell you that generating CRC tables and other complex heavy code which store values in global tables have never been proven to be much slower than doing so for local tables. If you want a speed advantage scope-wise, localize functions and variables, but a global variable or table here and there won't matter much.

Also, a dialog opening every so slightly slower the first time after the application started has nothing to do with AMS. For example, when I do this in PureBasic or C++, the first opening takes a little bit longer. (Not 1 or 2 seconds, a few ms). This is probably due to Windows API allocating memory for the window and performing the required steps for showing the window. This also happens when I open a secondary child window in PureBasic or C++

All the things you describe are not like that for every user. Also, I had to actually measure the delay and it was about 100ms more the first opening. This is normal, memory has to be allocated. The same goes for every window that will open. The first time it opened it took 220ms and the second time it opened it took 130ms...

[Cybergraph]

The time it lasts longer the first time differs about 50ms - 100ms, a user on a modern system will not even notice it. So not on every PC, always.

Also, when you declare a variable which holds an empty table, an empty table will be created in memory. Each time when you add a variable to that table, it will have to re-allocate the memory required, allocate memory for a new variable, assign this to the array or hash index for a Lua table and store everything in memory.

So for a table value, it doesn't really matter, considering each key / item in the table will have to be initialized just like any other variable. Don't forget that all variables (local or global) will just be keys inside a table object. The local variables in Lua 5.1 will reside in the function environment (which is a table) and the global variables will reside in _G (which is also a table). Local variables will always be slightly faster than global variables due to the check for variables in the scopes up to the global scope, but the use of global variables is not recommended at all in Lua.

Keeping that in mind, I've written a lot of Lua code in my life and I can tell you that generating CRC tables and other complex heavy code which store values in global tables have never been proven to be much slower than doing so for local tables. If you want a speed advantage scope-wise, localize functions and variables, but a global variable or table here and there won't matter much.

Also, a dialog opening every so slightly slower the first time after the application started has nothing to do with AMS. For example, when I do this in PureBasic or C++, the first opening takes a little bit longer. (Not 1 or 2 seconds, a few ms). This is probably due to Windows API allocating memory for the window and performing the required steps for showing the window. This also happens when I open a secondary child window in PureBasic or C++

All the things you describe are not like that for every user. Also, I had to actually measure the delay and it was about 100ms more the first opening. This is normal, memory has to be allocated. The same goes for every window that will open. The first time it opened it took 220ms and the second time it opened it took 130ms...

... also because (tell me if I'm wrong) we all are not designing applications needed to control and check precision of atomic clocks...