Quote:
Quote:
Quote:
Quote:
|
Now that we are already talking about "efficient" Lua code, I have a few things I've been wondering about lately.
String concats, I know they are bad to do many times as it will create a new sting each time, but I was curious which one of these lines would be the best to use? Does a concat of an empty string mean much? Code:
label:SetText(FormatTime(timeLeft)..(showTotalTime and " / "..duration or "")); Code:
tbl.name, tbl.value, tbl.color = name, value, color; watchout Doh, you're right, ah well, not like it really means anything :rolleyes: |
Quote:
Code:
local clock = os.clock Code:
1 multi line assign took 11.77000 secs |
I completely forgot I had a lua5.1.exe lying around, so I just ran your code and come up with this, same results really, just faster. What did you use to run the code in?
Code:
1 multi line assign took 2.01600 secs Using your benchmark code, I tried running this to see which was fastest. It is more or less a copy/paste from one of my addons, from an OnUpdate script on a timer. Code:
local text; Code:
1 no concat took 13.15700 secs Code:
1 no concat took 23.56300 secs |
Quote:
|
Just updated my post above, while you posted, with some tests about string concats.
What about meant with where you ran your code, was which program, was it also lua5.1.exe? |
Yeah I'm using lua 5.1 on Fedora Core 10, on an Asus Aspire One.
Quote:
So if my understanding is correct, if a table lookup is O(1) then the size of the table doesn't affect the speed of the lookup? |
O(1) means that the time taken to perform an algorithm is a constant, whatever the input size. O(n) means that the time is a multiple of the input size (plus a possible constant).
Algorithm complexity is interesting as a tool to compare how algorithm scale with the input size. But what this tool doesn't tell you, is which algorithm is the fastest. An O(1) algorithm that takes one hour to complete is worthless compared to an O(n) algorithm that takes seconds to do the same for reasonable input sizes. |
Thanks for the explanation IBLJerry.
I'm a little curious though, can anyone give an example of an algorithm that doesn't scale with the data? |
"Determining if a number is even or odd; using a constant-size lookup table or hash table" is the example delivered by Wikipedia.
|
You guys are vastly over-complicating this, from a fun abstract random curiosity type of question sure, but for practical applications, all you really need to ask yourself is "Am I doing something really stupid?" The majority of the mistakes I see new people make are they create a static table every time a function is loaded instead of once on file load like you see below. Creating options tables only when needed instead of all the time as Slakah mentioned as well.
Code:
function foo() Code:
local staticColor = { r = 1.0, g = 1.0, b = 1.0 }; Eggi touched on this, but always ask yourself what the function is doing. If you're writing a mod for checking if the player has a buff and warning them, efficiency is a good goal but you shouldn't worry about it; on the other hand, if you're writing a mod to monitor the auras of 25 people in a raid during combat, then efficiency should be something you care more about. If you it requires user interface (GUIs, and that kind of thing) or they can't do it in combat then efficiency should be a lot lower on your list. |
More tips:
|
If I want to store a list of strings, let's say for some kind of filter, what is the fastest way to do it, store them as keys, or as values?
Storing them as keys looks better code wise, but that doesn't mean it is faster. But based on the previous talk in this thread, I assume that keys is just as fast, if not faster? Code:
if (tableFilter[name]) then Code:
for index, entry in ipairs(tableFilter) do |
Keys are always faster for that sort of thing. Iterating over the table makes a bunch of function calls.
|
Quote:
|
Which wouldn't be "that sort of thing" (finding out if the value is in the talbe)
|
To save a function call, many uses next() as the iterater in a for loop, why not do the same for ipairs(), should be easily obtainable using this code. Or is there an iterator function already available for array type tables, like next?
This would probably be quite silly normally, unless it's code run often like in an OnUpdate script. Code:
local iterator = ipairs(_G); |
You'd only save one function call out of all the ones made while looping. It'd be better to optimize so that you don't need to iter at all.
|
Quote:
|
Regarding events, I was always wondering would be the better coding style:
a) Catching all events of one type (i.e. UNIT_BUFF) in one central location and distributing them to the relevant frames (i.e. RaidFrameNumberXY), b) Having decentralised event handlers for each frame, each listening for all relevant events. Evidently, variant b) uses more CPU time, since each event would have to be analysed once for each frame, but having frames as independent building blocks seems to be more manageable and extendable. |
All times are GMT -6. The time now is 12:01 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI