| 04-13-2008, 05:04 AM | #1 |
This is how I'm about to start attaching my stuff:  JASS:library DataStore globals private handle array hand private integer array data private integer cur = 0 endglobals function AmountStored takes nothing returns integer return cur endfunction function SetData takes handle h, integer n returns nothing local integer i = 0 loop if hand[i] == h then set data[i] = n return endif set i = i + 1 exitwhen i > cur endloop set hand[cur] = h set data[cur] = n set cur = cur + 1 endfunction function GetData takes handle h returns integer local integer i = 0 loop if hand[i] == h then return data[i] endif set i = i + 1 exitwhen i > cur endloop return 0 endfunction function RemoveData takes handle h returns integer local integer i = 0 local integer n loop if hand[i] == h then set n = data[i] set hand[i] = hand[cur] set data[i] = data[cur] set cur = cur - 1 return n endif set i = i + 1 exitwhen i > cur endloop return 0 endfunction endlibrary It's also easy to add extra keys into, so you can use it exactly like the gamecache. So if you add a string key, you can do something like SetData(unit, SCOPE_PRIVATE, struct_id). My question is, why hasn't this been done before? It's simple, and it works well on the tests (admittedly limited) I've done. |
| 04-13-2008, 05:30 AM | #2 | |||
Quote:
Quote:
The reason nobody uses it ... is that gamecache is faster. Any test that would tell you that an O(n) function is a huge amount faster than any other system, must be wrong. If you are skeptical, post the actual tests. -- And it is currently wrong, as in... a lot JASS:call SetData(u,2) call BJDebugMsg(I2S(GetData(u))) //shows 2 call GetData(u,5) call BJDebugMsg(I2S(GetData(u))) //shows 2 Quote:
But ... all of them would share the same array, which is subject to both the 8191 indixes limit and the fact your algorithm is linear... -- It would be easy to get some bad test and show that this is twice as fast than other systems, mostly because the most important factor usually is the number of function calls, your system requires only one function call. But if you try it in a real map, after you use it with, say 20 objects, it will be much, slower. Edit: It is not a terrible idea if you can make it multi instanceable (As in every system/spell uses its own array) and you have a limit of around 6 instances per system or spell, should be faster than CSData derivatives. But if you use it for heavier things / don't isolate the arrays, it will get very slow. Picture 50 [0.04s] timers , and for each timer you attach one of these values, your function alone will require 25*51*25 things to do per second. If you had 100 [0.04s] timers the result would be 50*101*25 things to do per second. Now if you had 100 [0.04s] timers and you also had it in use by other 500 misc handles, you would need a crazy ((300*601)-(399*200))*25 things to do per second... |
| 04-13-2008, 05:46 AM | #3 |
| 04-13-2008, 07:11 AM | #4 |