System Timer32

[Jesus4Lyf]

I was wondering if this is going to cause any performance issues (fps) if I have, say, around 30-40 active struct instances in use with this. My current search is to find something that can handle such a number of low frequency calls without a huge amount of performance loss as in concern of the user/player.

This can probably handle 800 instances of simple stuff nicely.

The goal of this was not actually to be the most efficient system so far - it was to be the most efficient system ever possible.

(Oh, and yeah, uberfoop is pretty much right.)

 

[Kenny]

Question: How much slower would this be if you used a timer instead? I just find it comforting to know I don't have a high frequency timer doing nothing in the background (i.e pausing it when necessary). Even though it is not a big issue, I was just wondering.

Also, is it possible to remove the private keyword from next and prev so that they can be used in user defined functions? Obviously it would only be for personal use, but I find this system very cool and I need to run some small O(n) type functions that need a list of struct instances, so I thought that could be handy.

EDIT:

Oh and another question: Would there by any chance be a compile error due to the possibility of using two onInit methods (one from your module and another from the spell/system/whatever we are using it in)? I remember using something similar a while ago, and even though it was private (just like yours is), it still gave me errors.

 

[Jesus4Lyf]

Yes, there is that compile error. I could allow users to specify a T32_onInit method though, if people think that's worthwhile. But I believe JassHelper is meant to fix that up some time anyway. Still, the T32_onInit is an option...

In regards to your other questions, a high frequency timer going in the background isn't an issue, but removing it would remove a variable amount of efficiency: 1% at around 10 instances per struct type, maybe 5-10% (untested) for 1 instance per struct type.

You could make those public, but that list only contains structs that are firing the periodic method... Seems a little odd to need to iterate over those specifically.

Originally I was going to make the background timer pause and such, but I believe that would actually be less efficient than letting the DoNothing conditions run. The speed gain for adding/removing instances is probably more useful.

 

[Kenny]

Yes, there is that compile error. I could allow users to specify a T32_onInit method though, if people think that's worthwhile. But I believe JassHelper is meant to fix that up some time anyway. Still, the T32_onInit is an option...

I think I would find that option very useful until it is fixed in JassHelper.

In regards to your other questions, a high frequency timer going in the background isn't an issue, but removing it would remove a variable amount of efficiency: 1% at around 10 instances per struct type, maybe 5-10% (untested) for 1 instance per struct type.

The pausing isn't really a big issue to me, I was just wondering what the effects of switching over to a timerwould be.

You could make those public, but that list only contains structs that are firing the periodic method... Seems a little odd to need to iterate over those specifically.

It's just for a spell that I wish to use T32 for. Its quite intensive, and I thought making them public is better then using a unit indexing system (for now).

Thanks for the reply.

 

[RaiJin]

ah i understand the linked list stuff a bit more now, but i don't ever think ill get the hang of it to be able to use it

 

[Nestharus]

Nvm nvm : D

 

[Jesus4Lyf]

...

Why would you benchmark the accuracy of a timer system like this?

 

[Nestharus]

nvm nvm : D.

But uhm, Jesus4Lyf, you should show some results of this thing's accuracy : o.

 

[Jesus4Lyf]

I don't see why.

 

[Tyrande_ma3x]

Hmm, I wanna suggest a public FPS constant. I noticed I needed such a thing while doing some periodic stuff and had to declare my own one.

globals
    public constant real PERIOD=0.03125
    public constant integer FPS=R2I(1 / PERIOD)

 

[Jesus4Lyf]

Hmm.

What did you need it for? /PERIOD == *FPS...

But I'm happy to add it if you like.

 

[Troll-Brain]

A simple comment sounds more "reasonable", maybe it isn't obvious for all.
It's not like adding a such constant is relevant or not, but fairly useless, the only use would be PERIOD.

 

[Tyrande_ma3x]

For example, an immolation spell. Every PERIOD I'm checking if the caster is dead or not so I can remove the instance. For the dps I'd need ticks to count when 1 second has passed and that's why I need the FPS constant to reassign the ticks back to 32 (since very PERIOD I subtract 1). Other than that, it could be used in similar situations where you'd need to count when 1 second has passed in the periodic method...

 

[Troll-Brain]

It's a such specific case.
If he did that , then he could also make it for 1.1 s , 2.3 s and so one

R2I(wanted time/period) is not that hard.

 

[Tyrande_ma3x]

True, but the normal 1 second FPS is more commonly used. ^^ Still, it's just a suggestion.

 

[Jesus4Lyf]

Done. I think it is a nice addition. I think I found once while coding with it that I needed a similar thing anyway.

Also added a debug message for if a struct has startPeriodic called for it while it is already on periodic.

 

[Dr.Jack]

Approved!
Thanks for contributing!

 

[Kenny]

Sad face. You updated to add a constant and some debug messages, but not to make this compatible with a majority of spells/systems that use structs and the onInit method. I wouldn't mind seeing some compatibility here until JassHelper is fixed.

 

[Jesus4Lyf]

Approved!
Thanks for contributing!

Thanks, Jack!

make this compatible with a majority of spells/systems that use structs and the onInit method.

Actually, I tried this. It botched something to do with inheritance. Example:

struct SpellShare
    real x
    real y
    unit caster
    unit target
endstruct

struct MySpellInstance extends SpellShare
    private static method T32_onInit takes nothing returns nothing
        ...
    endmethod
    private method periodic takes nothing returns boolean
        ...
        return false
    endmethod
    implement T32
endstruct

This actually bugs! (At least in my version of JassHelper.)

It looks for T32_onInit inside of SpellShare even though it finds periodic inside MySpellInstance. So my attempts of implementing it failed.

However! You can still use scope initialisers to run a static "init" method in the struct, which is what I've resorted to in my own spells until JassHelper fixes up modules. So I think you'll have to bug Vexorian on this one...

PS. That is what I'm doing in my own map. It's quite a serious issue that it bugs, it means I wouldn't be able to use T32.

 

[Kenny]

Oh shit... Sad face indeed. That sucks. I guess I will just use scope initialisers then.

Anywho, mad system, hope JassHelper gets fixed quick smart so that this can be even more useful.