System PII - Perfect Item Indexing

[kingkingyyk3]

I am tested trigger is slow than timer.(Using hashing method)

 

[Cohadar]

while (p != null){
    if (p.evaluate()){
       p.execute();
    }
    p = p.next;
}

So when you have one condition on trigger (that returns false) the difference from timer is 4 bytecode instructions.
So yeah they have exactly the same performance, since no performance difference can ever be noticed in any real usage situation.

We already had discussion of real-usage vs testing-only performance in KT2 thread, lets not repeat it here.

Let me be clear: I have no intention of changing any code in order to satisfy peoples silly ideas of optimization.

EDIT:
my bad, not bytecode instructions but machine assembler instructions since it is safe to assume that trigger invocation is written in C++ rather than in jass

 

[Jesus4Lyf]

*Shrugs* I'm satisfied with that. Just wanted to know and be sure for my own systems.

Thanks for posting your findings.

Edit after thought:

while (p != null){
    if (p.evaluate()){
       p.execute();
    }
    p = p.next;
}

Wait, what? Why would it execute after every condition? I thought it was more like:

bool b = true
while (p != null){
    if (!p.evaluate()){
       b = false;
    }
    p = p.next;
}
if (b){
    t.execute();
}

 

[Blackrage]

Somehow, PDI is next...or PTI, PEI, or maybe even PHI.

 

[Jesus4Lyf]

I don't think destructibles have UserData. You'd have to do something nasty like what I think Azlier might actually be doing. But if Cohadar made PDI, you could actually bind them together into PWI (Widget)!

 

[Azlier]

Aye, I am making DDEA. It's not working!

 

[Cohadar]

Aye, I am making DDEA. It's not working!

Attaching is enough for destructables, they are never removed as far as I know.
(also they are mostly preplaced)

indexing as a concept makes sense only when you need to attach to something that might have MUI problems, and the only two handles of that type are unit and item (items are actually special kind of units)

@Jesus4Lyf
you are right. (obviously)

 

[Cohadar]

*bump*

Someone needs to approve this before it is forever lost in the depths of php.

 

[Sevion]

Well, this is pretty much PUI for Items, and I always found PUI really handydandy when doing stuff with Units. And since my opinion carry so much weight, I approve of this system.

 

[GetTriggerUnit-]

. And since my opinion carry so much weight, I approve of this system.

 

[wraithseeker]

.. Cohadar do you know your PUI broke my system because it overwrote existing struct on the unit?

I might use this for the new CIS library if you make it a module and we call .destroy instead of .release.
Not to mention struct stack must be allowed too.

Why don't you use modules like AutoIndex? It seems nicer and better to implement.

 

[Cohadar]

.. Cohadar do you know your PUI broke my system because it overwrote existing struct on the unit?

Do you realize your system is broken because PUI is not?

I might use this for the new CIS library if you make it a module and we call .destroy instead of .release.
Not to mention struct stack must be allowed too.

Just don't call anything, it is a better way.
If it was possible I would forbit destroying of PUI structs manually, but vJass does not have that capability.

Struct stack??

Why don't you use modules like AutoIndex? It seems nicer and better to implement.

Because modules cannot be used for properties.

Autoindex does not work the same way as PUI, it gives index to anything and everything so it can avoid complex algorithms.
If it suits you better you should probably use Autoindex.

 

[Jesus4Lyf]

.. Cohadar do you know your PUI broke my system because it overwrote existing struct on the unit?

Excuse me, but why on earth would you mention this is the PII thread?

The PUI thread is just fine for comments about PUI...

 

[wraithseeker]

Because the textmacros are almost the same.

  if .pii_data[pii] != 0 then
            call .destroy(.pii_data[pii])
        endif

Why would you want to destroy the struct if a struct is already active on the unit? What if I wanted multiple structs on a unit?

For example for a knockback system what if 3 knockbacks are active on a unit? It'll break the existing knockback on the unit before it's even finished.

>Because modules cannot be used for properties

Okay.

 

[Jesus4Lyf]

Please. No one wants a knockback system for items. So would you go comment in the correct thread?

Edit: You know I'm not sure that PII is that useful? I think the system should have the ability to make structs for items when they enter the map, automatically (based on filters and stuff). Hmm.