HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Speed of handle vars / tables again

09-09-2006, 05:21 PM#1
Vexorian
I am repeating this benchmark I am also making it more complete. I am just attaching the file, I don't want to write stuff, well here are my conclusions.
  • Biggest difference in execution time between handle vars and gamecache natives is the I2S(H2I()) combo, But the reason is not actually H2I but I2S , still calling those functions more times than you should is a good slowdown cause, and this is a good reason to use tables. (I2S uses like 4/3 of the time used by H2I)
  • Tables aren't too fast compared to gamecache natives either, but there is an exception and it is for GetTableLoc and the like (with auto return bug) they are as fast as using the native and return bug directly.
  • The auto flushing doesn't make stuff much slower, the difference is unnoticeable, also FlushStoredInteger is faster than StoreInteger, so auto flushing might actually speed up some operations.
  • Now if you are really worried about speed that's not a good reason to use the gamecache natives either, if you want fast, unreadable code go for the alternatives, or pay the cost of karukef's attach system.
Attached Files
File type: txtbench.txt (10.8 KB)
09-10-2006, 02:35 PM#2
BertTheJasser
I guess nobody uses handlevars anymore, so it's a kind of .. pointless?
09-10-2006, 02:41 PM#3
Vexorian
I wouldn't say that nobody uses handlevars anymore, also someone was bugging me about H2I's speed.
09-10-2006, 02:46 PM#4
BertTheJasser
Ok, then I must say nobody 'should' use handlevars anymore.
09-10-2006, 03:16 PM#5
blu_da_noob
Plenty of people still do. Check spell resource submissions.
09-10-2006, 04:04 PM#6
shadow1500
Quote:
Ok, then I must say nobody 'should' use handlevars anymore.
Gamecache is not that bad. Yes it is slow when you're using a 0.03 timer and get/store lots of gamecache data in it (i.e projectile spells). Its not bad when you're using it to get some information from a database (i.e items with random bonuses, they will stay for the whole game and cause arrays to use gamecache a lot faster). Gamecache is still useful in a lot of cases.
09-10-2006, 04:12 PM#7
blu_da_noob
I think he means handlevars, where I2S(H2I()) is computed each time.
09-15-2006, 03:42 PM#8
BertTheJasser
Blue is right-
09-15-2006, 10:15 PM#9
UnMi
Well, I would not know how to "not use" handle vars.
How can you be dynamic there?
09-15-2006, 10:26 PM#10
Captain Griffen
You could use some form of system to dynamically allocate space on arrays (which CSCache uses).

At present, I'm experimenting with using the return bug to speed up converting int to string, and it seems to work fine (with a little adjustment), and a considerable, but not massive, amount faster.
09-16-2006, 02:27 AM#11
Vexorian
I don't really think the speed improvement is worth the risk and they do fail when loading saved games, now if you have found a way to fix it then make it public
09-16-2006, 08:22 AM#12
Captain Griffen
Well, at present my idea is just generating a load of strings at start up (which could then also be done at loading of the game). That ought to work.

That's a stupid method, however. Using a few globals would be much better, something like this:

Collapse JASS:
function handleI2S takes integer i returns string
    set i = i - 1048576
    if i <= 8150 then
        return udg_I2Sa[i]
    elseif i <= 16300 then
        return udg_I2Sb[i-8150]
    elseif i <= 24450 then
        return udg_I2Sb[i-16300]
    else
        return I2S(i)
    endif
endfunction

Should be massively faster, and completely safe (just setup the globals at start up).
09-16-2006, 12:23 PM#13
Vexorian
I don't know, it is not like we store/load strings on many speed intensive processes.
09-16-2006, 12:34 PM#14
BertTheJasser
I would say ints are the type you can use for (almost) everything.
09-16-2006, 12:55 PM#15
Captain Griffen
Because everything except reals is an int, or is pointed to by an int.