[Snippet] TimerPool

[Nestharus]

This resource has moved here.

--

gone

 

[Bribe]

Magnifico, another Timer System. Just what was needed!

 

[Nestharus]

This is used by TimerTools

It's also better than TimerUtils

 

[Bribe]

Yours is RAM heavy and you don't create more in the chance of overflow. It also doesn't have Hash table support as a fallback in case the handle table flips back around to a Lower number during creation of those timers. Just letting you know the caveats.

 

[Nestharus]

I don't see why the handle table would flip

local TimerPointer tp = TimerPointer.create()
local timer t = tp.timer

 

[Troll-Brain]

Yours is RAM heavy and you don't create more in the chance of overflow. It also doesn't have Hash table support as a fallback in case the handle table flips back around to a Lower number during creation of those timers. Just letting you know the caveats.

IIRC handles id are not recycled instantly if there is a reference counter for this, it seems there is some delay, in other words this should be true :

local timer tim = CreateTimer()
local integer i = GetHandleId(tim)

call DestroyTimer(tim)
set tim = null
call BJDebugMsg(I2S(GetHandleId(CreateTimer())) +" =! " +I2S(i))

So since timers are created at map init it should be right.
About the "ram heavy", really that doesn't matter that much, overflow could be a problem though, i prefer a map even with some performance issue but still work than an "optimized" one but broken.

Don't get me wrong, i don't support this resource, as usual i'm just trying to be accurate and complete.

 

[Bribe]

The handles are not recycled instantly, but if memory serves somewhere around every 1024 handles or 8192 handles, if some of those handles were destroyed along the way it will wrap around back to handle 0x100000 and start the count up until it encounters a handle that is still in use. Don't quote those numbers, but one can BJDebugMsg the handle Id every 500 handles in a loop that basically creates and destroys timer handles as a test. I'll do this test again later today and come back with some more accurate numbers.

 

[Nestharus]

The handles are not recycled instantly, but if memory serves somewhere around every 1024 handles or 8192 handles, if some of those handles were destroyed along the way it will wrap around back to handle 0x100000 and start the count up until it encounters a handle that is still in use. Don't quote those numbers, but one can BJDebugMsg the handle Id every 500 handles in a loop that basically creates and destroys timer handles as a test. I'll do this test again later today and come back with some more accurate numbers.

This loop doesn't destroy any timers though : |

Be sure to like.. create 500 timers, and then destroy them. After that, create 2000 timers and see if it ever goes back down. That would be an accurate test.

 

[Troll-Brain]

The handles are not recycled instantly, but if memory serves somewhere around every 1024 handles or 8192 handles, if some of those handles were destroyed along the way it will wrap around back to handle 0x100000 and start the count up until it encounters a handle that is still in use. Don't quote those numbers, but one can BJDebugMsg the handle Id every 500 handles in a loop that basically creates and destroys timer handles as a test. I'll do this test again later today and come back with some more accurate numbers.

Well, i'm not sure i understand you correctly because my english is not that good, but again the timer creation is done at map init, so even if timers, or even other handles are destroyed before, inside an other init, it still should be fine, because how handles' id are recycled, again only if i remember correctly.
My guess is that handles id are ready to be recycled after the thread where the handle is destroyed, is closed. (asssuming you don't open a new one within this thread)
Let's say before a Timer(0), i think an handle id is not ready to be recycled if you don't have any delay since its destroying. (TSA, timer, whatever ...)
That worths a test. (and no i won't do it since i don't have wc3 installed anymore since a while)

PS : Btw i've edited my piece of code, the "null" part is mandatory not optional to be a valid test.

 

[Nestharus]

This resource was inside of Timer Tools. I took it out because it was a resource on its own. It was part of my effort to make the Timer Tools code more manageable.


This does not have the extra operation overhead of TimerUtils, overhead that I never particularly liked.

You say it uses more RAM, but for integers, it uses 32kb of RAM. If you had 1000 arrays, you wouldn't be at 32 megs yet >.>. That's almost nothing for RAM.


Don't make the RAM argument when a standard computer usually comes with a bare minimum of 8 gigs of RAM nowadays. Actually, it's 16 gigs now.

 

[Bribe]

Most people with that much RAM will not be playing WarCraft 3 but higher-demanding titles with eye candy.

People who play WC3 are more likely to have an old machine or a cheapo computer and WC3 is the best quality game they can run.

 

[edo494]

Most people with that much RAM will not be playing WarCraft 3 but higher-demanding titles with eye candy.

People who play WC3 are more likely to have an old machine or a cheapo computer and WC3 is the best quality game they can run.

I must be strong exception then, 8 GB of ram(32 bit system, so I can only use 4 anyways)

 

[TriggerHappy]

Don't make the RAM argument when a standard computer usually comes with a bare minimum of 8 gigs of RAM nowadays. Actually, it's 16 gigs now.

Stop making things up lol

 

[Frotty]

Don't make the RAM argument when a standard computer usually comes with a bare minimum of 8 gigs of RAM nowadays. Actually, it's 16 gigs now.

And maybe 1% of wc3's players have a "now" pc.
Most people I know have the bare minimum to run wc3 and lagg on ram/cpu extensive maps.
This is also one of the reasons wc3 is still "somewhat" popular on garena.
It has very low requirements, is free to play with garena and has lots of different maps that run on those requirements.

Also, you always take your chance on enhancing code making it execute a nanosecond faster. (like > instead of >=)
Today's standard is an SSD and a cpu with 4ghz per core. That stuff doesn't make a difference.

Bite me. Seriously.

 

[chobibo]

I must be part of the 99%, I only have 1gb ram.

 

[Nestharus]

It really doesn't matter.. we're talking 32k of RAM per array. If you had 1024 arrays in your map, which is probably more than any map will ever have, that's 32 megs of RAM.

I hope you see my point now.


It's just very frustrating when I have to argue about ridiculous stuff.



Memory is cheap, get over yourself.

 

[edo494]

tbh its not even 32k unless you start using 4096+ indexes

 

[Frotty]

It's just very frustrating when I have to argue about ridiculous stuff.

Yet this is all you do. ever.

 

[TriggerHappy]

I really don't like the preloading nature of this, and as others have pointed out it can be intensive on slower machines (huge percentage of war3 community). Since it's called at initialization, it will increase the maps load time which was one thing I hated when I had a slower pc. I understand that aspect alone shouldn't discredit a resource, but I do feel in this one it does. There are already many more useful, standardized timer systems out there. I also really dislike your idea of splitting aspects of a timer system up into multiple modules/structs. It just creates more useless dependencies.

I really think the community has all it needs in regards to attaching data to timers.

 

[Nestharus]

I really don't like the preloading nature of this, and as others have pointed out it can be intensive on slower machines (huge percentage of war3 community). Since it's called at initialization, it will increase the maps load time which was one thing I hated when I had a slower pc. I understand that aspect alone shouldn't discredit a resource, but I do feel in this one it does. There are already many more useful, standardized timer systems out there. I also really dislike your idea of splitting aspects of a timer system up into multiple modules/structs. It just creates more useless dependencies.

I really think the community has all it needs in regards to attaching data to timers.

once again, this is a rewrite of a current timer system

I am unwilling to fix that timer system when all of the code is in one gigantic library. It makes it impossible to debug.