[Snippet] Alloc Alternative

[Nestharus]

gone

 

[Magtheridon96]

debug private static boolean enabled = true

This can /easily/ collide with any other variable name in debug mode :/
Try something like enabled_p or debug_enabled or maybe some sort of obscure name like debug_e.
Anything is fine, just not 'enabled'.

 

[Nestharus]

It's private bro.. I can name it what I like.

 

[Magtheridon96]

Meh, approved.
No reason as to why I shouldn't.

You might want to link to Sevion's Alloc though.

 

[Yixx]

Not to be rude or anything, but how is this any different from Sevion's Alloc? I mean, yeah, you used a static thistype array instead of making it a private member, and you switched a few lines around which have no effect on functionality. I'm not arguing whether this should be approved or not, I'm just wondering, is it really any different in the end?

 

[Nestharus]

In no way was this influenced by Sevion's module.

Furthermore, just because someone made a resource doesn't mean that somebody else can't make that same resource but better. Being the first to submit something doesn't give you ownership of that something. Believe it or not, I was the one that started the trend of doing allocation with struct extends array. Bribe was the one that did the initialization of the local variable to the stack. Vexorian was the one that did recycler[this] = -1 for protection from double free = ).

Sevion didn't write his module perfectly, so it was only a matter of time before somebody else would submit a better version >.>.

Furthermore, this follow a different philosophy from the general Alloc. This one disables itself when it encounters an error rather than letting the map limp on and throw more errors. It also crashes the thread. This was a philosophy I came up with and have been doing in my own stuff for a while now. By this regard, you could have both modules, one for each philosophy. However, Sevion's still needs to be improved =P.

One thing you need to know that sets THW apart from wc3c and TH is that THW doesn't believe in set standards. So long as something has a use and does its job well relative to existing resources and to possible improvements, it gets approved. If it happens to deprecate another resource, that resource gets sent to the graveyard. The only reason BonusMod by Earth-Fury wasn't sent to the graveyard after Bonus was approved was because it generates the objects in it without the Lua framework (unsafe object generation). Generating bonuses requires Lua as there are many abilities, and some people are daunted by the Lua framework, which is why BonusMod stayed approved. It wasn't kept in the JASS resource section out of some respect for Earth-Fury. It was only kept for practical reasons.

If you look, we have two DDS systems in the JASS section (we used to have 3, but Purge's got deprecated). I actually fought to get the second one approved saying that it followed a different design from the one I wrote.

In the same regard, Bribe used to have a Dummy system that was approved that he spent a lot of time working on. I wrote another one that deprecated his as mine had better behavior and he ended up having to graveyard his own.

We can even look at a current case. I wrote a DummyCaster lib, and then I wrote a Spell lib and requested that DummyCaster be graveyarded. The Spell lib was in response to Mui Dummy Casters as the author wouldn't listen to me, so my Spell lib deprecates DummyCaster and Mui Dummy Casters.

We can look at save/load. I wrote 1 save/load system that got every other save/load system in the Spells section rejected.

If you see a way to improve something, improve it and submit it and that old thing will be graveyarded if it is inferior to your new thing ; ).

 

[Yixx]

That all makes perfect sense, and I can only agree with that view, but it does not answer my question. That might be because I did not state it clearly enough, so I will ask it in a different manner:

How is this one better from Sevion's Alloc module, except for crashing the thread when too much instances have been allocated or when an invalid instance is deallocated? (and when the system is not enabled of course)

 

[Nestharus]

this == 8191 (not 8190) and local thistype this = recycler[0] (more memory and slightly better performance). All in all, it's the exact same as Sev's excluding what you brought up.

But once again, two different philosophies. Should the map limp on (like sev's does), or should it immediately halt (like this one does). Both are valid options, so it is up to the map maker to decide, which is why Sev's wasn't graveyarded.

 

[Anachron]

Nes, why do you have a static == 8191 check, when it is allowed to have more than 8191 instances of the same struct by setting the instances with struct[INSTANCES]?

Another thing is, as far as I have seen this does NOT provide any more features than the default allocation and deallocation.

 

[Nestharus]

Nes, why do you have a static == 8191 check, when it is allowed to have more than 8191 instances of the same struct by setting the instances with struct[INSTANCES]?

Another thing is, as far as I have seen this does NOT provide any more features than the default allocation and deallocation.

You can't have more instances than 8191... if you do that, ur no longer working with an array

 

[Anachron]

Oh yeah, which is why your system only works if you keep that in mind.

 

[edo494]

ehmm...by the way
shouldnt

            debug set this = 1/0
            debug set enabled = false

in reversed order? (set enabled = false first)? because this way, the thread crashes before it is set to false so the enabled is kinda useless

 

[Magtheridon96]

Yes. Yes it should.

 

[Nestharus]

Fixed

 

[Nestharus]

Updated to be compliant with standard error message output and behavior

 

[edo494]

you know you could just display message thistype: error allocating and it will be changed to the proper name of the struct with Vexorians JH(dont know abou Cohadars), bevause with your throwerror tou dont know what type of struct was allocating

 

[Nestharus]

Thanks, didn't know that =), I'll update it

 

[Nestharus]

Added new leak checking stuff =)

 

[Sevion]

Sevion didn't write his module perfectly, so it was only a matter of time before somebody else would submit a better version >.>.

Nice job!

Been a long time since I looked at any WC3 related stuff, but I didn't know Alloc was still in use after so long.

 

[Nestharus]

Removed some code + speed boost

 

[Nestharus]

Did a very minor update. Set index 8191 to 0 at the beginning of onInit to make it so that the array doesn't reallocate over and over again. It'll go to the max size and be done.

 

[Magtheridon96]

Okay, hold up.

        private static method onInit takes nothing returns nothing
            local integer i = 0

            set recycler[8191] = 0 //so that the array doesn't reallocate over and over again
            
            loop
                set recycler[i] = i + 1
                
                exitwhen i == 8190
                set i = i + 1
            endloop
        endmethod

How does this NOT hit the op limit?

 

[Nestharus]

Look at the JASS init globals stuff. You can initialize a few arrays before you hit the op limit. I also tested that to see if it did or not to make sure, and it didn't.

 

[TriggerHappy]

You're allowed to do like 20,000 simple operations before you hit the op limit iirc

 

[PurgeandFire]

@Mag: I thought the same thing a while back. All module initializers are called under ExecuteFunc(), so the op limit doesn't become much of an issue (haven't tested with cohadar's jh tho).

 

[chobibo]

@TriggerHappy: 30K continuous ops, according to this.

 

[TriggerHappy]

My tests show this is ~5% faster than standard allocation for those who were wondering.

However for some reason (even with trying many variations) the first time calling the custom allocation it's ~15-20% faster. No, I didn't test in debug mode.

    struct standard
    endstruct
    
    struct alloc extends array
        implement Alloc
    endstruct
    
    private function Actions takes nothing returns nothing
        local integer sw
        local integer i
        local real array ticks
        local string output = ""
        local boolean b = true
        local integer f=0
        local integer g=0
        local integer instance
        
        set i  = 0
        call TriggerSleepAction(0)
        set sw = StopWatchCreate()
        
        loop
            exitwhen i == ITERATIONS
            set instance = alloc.allocate()
            set i = i + 1
        endloop
        
        set ticks[1] = StopWatchTicks(sw)
        call StopWatchDestroy(sw)
        
        //set output = output + I2S(ITERATIONS) + " iterations of Test #2 took " + I2S(StopWatchMark(sw)) + " milliseconds to finish.\n\n"
        
        set i  = 0
        call TriggerSleepAction(0)
        set sw = StopWatchCreate()
        
        loop
            exitwhen i == ITERATIONS
            set instance = standard.create()
            set i =i + 1
        endloop

        set ticks[0] = StopWatchTicks(sw)
        call StopWatchDestroy(sw)
        
        //set output = I2S(ITERATIONS) + " iterations of Test #1 took " + I2S(StopWatchMark(sw)) + " milliseconds to finish.\n"
    
        if (ticks[0] > ticks[1]) then
            set ticks[2] = 100 - (ticks[1]/ticks[0] * 100)
            set output = output + "Test #2 was " + R2S(ticks[2]) + "% faster than Test #1\n\n"
        else
            set ticks[2] = 100 - (ticks[0]/ticks[1] * 100)
            set output = output + "Test #1 is " + R2S(ticks[2]) + "% faster than Test #2\n\n"
        endif
        
        call DisplayTextToPlayer(GetLocalPlayer(), 0, 0, output)
    endfunction

 

[Nestharus]

However for some reason (even with trying many variations) the first time calling the custom allocation it's ~15-20% faster. No, I didn't test in debug mode.

that has to do with array initialization likely ^)^

 

[PurgeandFire]

calculateMemoryUsage() is bugged atm.

set count = checkRegion(start, end)

->

set count = count + checkRegion(start, end)

P.S. I don't really agree with the name of calculateMemoryUsage(). IMO it is misleading. I would name it something like calculateActiveInstances() (not-so-great name, just an example). Atm, this takes up a fixed memory of 4*8192 bytes = 32768 bytes = 32 kb per struct, which I refer to as the "memory usage". idk about you.

edit: It is minor, so no biggie. Just a personal qualm.

 

[Nestharus]

Fixed it

not changing the method name, already using it all over the place ;p

Frankly, I just don't have the motivation to do much with wc3 anymore. I'm not gung ho enough to change a method name used in several other resources :\.

Every time I start to work or do anything, I lose all my motivation after a few moments >.>. It'll be a long time before I recover and am able to work again =).

 

[chobibo]

@TriggerHappy: It must be because the array indices are already allocated on map initialization. The first call, in the case of the default allocator, will allocate the array, while the succeeding increase would just resize it. Just my guess though.