System Faster Table

[Waaaaagh]

You should probably warn that your system breaks after saving and loading the map.

The string table is deemed to be safe, until you load a saved map.

What appears to happen is that the old string table exists yet any new strings, regardless if they were in the old table, are re-created. Using ItoS on an old string (created before the save/load), the string located at that spot can be retrieved, but the second it is used as a string, it is casted to its new table location.

 

[Jesus4Lyf]

Thanks for that, didn't know! Will add that on the doc somewhere next version. :thup:

Does gamecache carry over?

 

[Viikuna]

Yes I think, because saving and loading doesnt affect handle ids. Strings position in string table is not important for gamecache.

 

[Jesus4Lyf]

>Yes I think, because saving and loading doesnt affect handle ids. Strings position in string table is not important for gamecache.

Mmm, that much makes sense, but I'm wonder if saving and loading works for gamecache in general, not just H2I attaching. If anyone has tested it and would like to let me know, go ahead. Not overly fussed.

 

[SerraAvenger]

I doubt they do.
Here are two versions that do not use GC either:
http://www.thehelper.net/forums/showthread.php?p=719614#post719614
And my doubtable approach:
http://www.thehelper.net/forums/showthread.php?p=792976#post792976

I'ld prefer damien's maps though.

 

[Jesus4Lyf]

Thanks for that, SerraAvenger.

Damien's does not support breaking the 8191 limit like Table does (and it doesn't seem to actually run it's textmacro?) and your own is definitely not written with the Table interface.

As said, this is meant to be a copy-over implementable system. I'll get some hashing going on the string ids soon enough (been busy) and I'll figure out a decent method to avoid colissions without dropping too much speed.

Furthermore, Damien's does not seem to flush. This is important in a copy-over implementable. I'll be writing this, too.

His even has a restriction of "Don't forget to clear entries after use"?

 

[RaiJin]

whats this Table and TableX or w/e needed for anyhow? i always wondered that

 

[Jesus4Lyf]

It's for super stable attaching, essentially.

You create a table, and then in that table you can attach to handles, strings or integers, without any limit or restraints whatsoever. So you can attach, for example, to an integer of 2958271 or handle number 20,000 and it works fine. Or, (and this is the one thing that as far as I know is unique to Table/Table-X) you can attach to strings. :thup:

The "problem" (and I use that term loosely) with Table is it's slow because it's just a wrapper for gamecache. A solution is Table-X, which simulates gamecache without actually using it. The theory is that any map with Table can have Table-X coppied over the top of it for an efficiency gain. Good fun.

 

[TheDamien]

Thanks for that, SerraAvenger.

Damien's does not support breaking the 8191 limit like Table does (and it doesn't seem to actually run it's textmacro?) and your own is definitely not written with the Table interface.

Maps wasn't meant to be like table. It came into existence as the result of experimentation with textmacros, library_once and S2ID, and my personal need for an instantiable, associative container that supported iteration and (eventually) sorting. As I recall Table didn't actually exist at that stage.

The textmacro is the system, the idea being that you could instantiate the textmacro for whatever type of map you needed. As you can see, it no longer uses S2ID which I disposed of in favour of hashing.

In retrospect gamecache ought to have been used. I'm not convinced that hashing is that much faster in practice and gamecache has turned out to be only a factor in many bugs, with things like misuse of DestroyTrigger and I2H being the real culprits.

I didn't have an option for size because I reasoned that no one would have 8191 maps or 8191 entries among all maps at any given time.

Furthermore, Damien's does not seem to flush. This is important in a copy-over implementable. I'll be writing this, too.

clearValue is the method for removing an entry from a Map.

His even has a restriction of "Don't forget to clear entries after use"?

That is not really a restriction. It is necessary in an abstract sense, given that Maps are collections of values as well as hash tables. In the first version there was no collection functionality and entries did not need to be removed.

 

[Jesus4Lyf]

Hey there! Thanks for the reply.

>clearValue is the method for removing an entry from a Map.
What about reset? In other words, clear all values? I actually meant reset not flush.

>Maps wasn't meant to be like table.
Then we're not in competition anyway. I stress again that this is for copying over Table. Serra just said that Maps did what Table-X does, and I was pointing out that it doesn't. Table-X copies over Table.

>misuse of DestroyTrigger
Can you tell me more? Don't know if I've heard of this one... Or did you mean DestroyTimer?

ANYWAY!

For those who were beginning to wonder if it was ever going to really happen... HERE IT IS! Version 1.01 release. My testing indicated that it's perfectly stable and ready for community testing. If you have a map with Table in it, do us a favour and stick Table-X in for a test run and see if any bugs come up. Aside from that, I tested it myself, including hashing and collisions and stuff, and flushing, and it seemed to work fine. :thup:

So this should now perfectly cover Table. I still need to bench test it to see if it's actually faster than GameCache, lol.

 

[Viikuna]

>misuse of DestroyTrigger
Can you tell me more? Don't know if I've heard of this one... Or did you mean DestroyTimer?

Its something they discovered at wc3c. If you destroy a trigger that is triggering, it somehow fucks up handle count ( triggers handle id is not properly recycled or something like that ) , and you might get two handles with same id ( handle stack corruption )

Thats why some people feel uneasy when using dynamic triggers.

 

[Jesus4Lyf]

>If you destroy a trigger that is triggering
Does this include TriggerEvaluate()? Is this only for triggeractions?

Well, I assume you don't have all the answers, but thanks. Any link to thread?

Anyway, Table-X is ready to roll... (attempt at staying on topic XD)

 

[TheDamien]

What about reset? In other words, clear all values? I actually meant reset not flush.

.delete would flush values. I didn't think to add something like .reset at the time; I guess I figured that it wouldn't be particularly useful.

At any rate, you can iterate through the Map and flush whatever you want.

Then we're not in competition anyway. I stress again that this is for copying over Table. Serra just said that Maps did what Table-X does, and I was pointing out that it doesn't.

It does in the sense that it replaces GC, and also that it used S2ID at some stage. I think using the string table for attaching is more trouble than its worth, and there is a reason that it doesn't typically appear in attachment systems.

Can you tell me more? Don't know if I've heard of this one... Or did you mean DestroyTimer?

There are sinister bugs that can arise from using DestroyTrigger when the trigger has actions or if the trigger is executing. I'm not sure of the particulars but I know gamecache has been implicated in some of these bugs (and even if gamecache doesn't cause bugs, careless use of it can).

If Vexorian uses gamecache in Table then I can only assume that it isn't particularly bugged, at least by itself.

 

[Viikuna]

Well, I think Cohadar says that Coditions and Evaluate are safe, and some say something else.

link

About handle stack corruption:

link

 

[Jesus4Lyf]

Thanks for the links!
I learned something today after compulsively reading every page of those two threads.

Spoiler

In my maps I downright ban the following:

• TriggerSleepAction
• ExecuteFunc
• H2I
• I2*
• Return bug abuse of any sort, actually
• Trigger actions, utterly (except for GUI stuff, etc)
• DestroyTimer
• GameCache

I never get ANY problems. I haven't seen any problems involving DestroyTrigger with all of the above outlawed. (Yes, I do plenty of attaching, yes, without H2I.) In writing Table-X the only thing I've done that I wouldn't usually do is use H2I. To be honest, I've never attached to string id's either until now.

I don't believe there's any bugs with gamecache the way Vex applied it in Table. However, I don't believe there's any point to using gamecache, as it is, apparently slow, and if Table can have gamecache removed from it (and Table was just a wrapper for it) then anything can go without it (as long as it doesn't require stable save/load).

>I think using the string table for attaching is more trouble than its worth, and there is a reason that it doesn't typically appear in attachment systems.

Why is that? Is there any other way to attach to strings without gamecache or Table-X? And still be fast?

 

[Viikuna]

Well, gamecache is not the fastest, but it is fast enough.

For timers we use struct arrays and TimerStacks or systems like KT2, which are really fast, and this is understandable, because timers usually generate lot of lagg, if not coded in some fast way.

Of course you can make a nicely working map by using gamecache for timers, and it works just fine, ( DotA ) but because there is easy ways to make things faster, people use them.

The best thing in Table is that it has no limits or any other downsides ( its safe ). Its just lil slow.

So if you can make system which has all the good sides of Table + its faster, everybody will use it, even if speed is not so important than with timers.



Actually, I only use Table for attaching to some weird handles like rects maybe and "hashing" integers to smaller ones ( array indexes ) in some rare cases.
In other words: Table is rarely needed, but when it is needed it does its job just fine.

Btw, I found this thread about string index stuff, if you are interested: link

edit. oops, forgot hte link

 

[Troll-Brain]

I personnaly hate attaching systems for something else than Timers, a struct + Table do the job (and eventually remove detection for units).
But maybe i'm wrong

Anyway it's a good idea (in theory), i just wonder if using 2 return bug won't be to much slow.

 

[Jesus4Lyf]

>and it works just fine, ( DotA )
DotA would probably not lag at all, even on wtf mode of it used KT2 instead. Currently, it's often unplayable. And even in a normal 5v5, the big battles lag me down to about 4 fps.

>So if you can make system which has all the good sides of Table + its faster, everybody will use it
Bah. At current version (1.01) gamecache version is faster. Table-X is 7.9 nanosec, Table is 4.3 nanosec. This is for one write and then one read.

Version 1.00 without hashing and stuff was 5.5 nanosec, still slower. And if I inline version 1.00 and tighten it up, I get 2.5 nanosec. So I might be able to get this faster. But I need to inline stuff. We'll see how I go. Of course, if I don't get it faster, it's useless (except for that gamecache hack exploit that was talked about lately?). So much effort, might be for naught...

 

[Troll-Brain]

Maybe the new feature of vJass will help you : module

 

[Jesus4Lyf]

Is that even released yet?

And no, I believe it won't help. Last I saw module was just a fancy text macro.

I've gotten this down to 4.5 nanosec. I bench tested Table and it was 4.8 nanosec! SUCCESS! :banghead: 7% difference.

Problem is, when I switch to extended arrays (in other words, over 8190 max attachments) the speed goes down to 6.1 nanosec! It's reliably faster until then, and reliably much slower thereafter.