array entry limit question

[SanKakU]

does it improve loading time to do [n] after array declarations

example:

globals
camerasetup array customCAM
real array customCAMrotatereal
real array customCAMrollreal
real array customCAManglereal
real array customCAMdistancereal
real array CAMX
real array CAMY
integer array earngold5
camerasetup array CAM
string array ICON
string array RANDOMTIP
integer array RUNNERTYPEID
integer array CHASERTYPEID
integer array SPECIALCRITTER
integer array diadifint
unit array runnerSERVANT
unit array RUNNER
unit array CHASER
button array diadifbut
//...more globals which are irrelevant to the discussion
endglobals

i have more than these, these were just the ones in one section of the map, although this is most of them...
anyway what are the differences between say doing the above and doing numbers for them, like this:
integer array RUNNERTYPEID[26]
integer array CHASERTYPEID[10]
they both are compiling and functioning just fine.
i am pretty sure picking numbers that are too low is a problem, but numbers that are the right count of entries in the arrays or just a little bit above the count of the entires in the array are better to have than leaving it all blank, isn't it? and if so, what are the differences?

 

[Dr Super Good]

WC3 arrays are arraylists and as such expand dynamically as more space is needed up to 2^13 indicies.

Vjass or any other preprocessor language is bound by this rule. Any complex behaviour they produce creates a complex JASS script bound by the same rules as normal JASS is.

Vjass impliments that support to allow parallel arrays for larger than 2^13 indicies but at the cost of slower acess. It also is used in its multi demensional arrays to calculate the space allocation the array use be divided into.

 

[PurgeandFire]

Array [] size definitions are a feature of vJASS that allow you to use indexes greater than 8191. If the size provided is greater than 8191, then they will create special "set" and "get" functions for the variable. If the size provided is 8191 or lower, then it will simply do nothing, as that is the normal array size.

So if you do this:

    globals
        integer array funB[942]
    endglobals

It won't be any different than a normal array. It would be the same as integer array funB. However, if you do something like this:

    globals
        integer array funB[20000]
    endglobals

It will create functions for getting and setting. They basically duplicate the variable and assign all higher indexes to the duplicate. (by using index-8191, or more depending on the index you chose)

EDIT: DSG beat me to the post.

 

[SanKakU]

uhm, that's interesting, but...i didn't understand anything of what dgs said and only some of what you said, lol.

 

[PurgeandFire]

Basically, there is no difference between integer array fun[50] and integer array fun, to answer your question.

 

[SanKakU]

hmm..i'm not convinced, i could time it, but i'm almost certain it made the map load faster.
it could just as easily have been some abilities i didn't add to the xedummy unit for preloading.

whatever the case, it seems i've shaved off about 20 seconds of loading time from version 0.96o to 0.96p. i'm sure it's less of a difference for people with faster computers. still, i used to abhor(especially my the ancient frontier loading time) my map loading time...i think i'm getting around 30 seconds or so for dota usually but it was higher for my map. i think all those extra preloading attempts were mostly to blame...i found out you don't just preload custom abilities(which i supposed was a good thing), you just preload the abilities that you add to units via triggers. anyway from version 0.96o to 0.96p there's about a 20 second loading difference, from 60 seconds to 40 seconds. and i'm pretty sure i couldn't've removed anymore than one or two of those preloading attempt things that i made. if there's any additional loading saving time, it pretty much has to have come from the array declaration differences as far as i can tell.

another thing i'm running into is i found this interesting library called itemdex...and it got me thinking about how necessary AIDS and/or Table libraries are in my tag map.
if i remember right i'm only using aids for the item charge merging for ammo stacking for my items. so indexing units is really not necessary...and yet i don't really know how to change the //INVENTORY DATA FOR UNITS(i renamed the library (it was called liked UNITS' INVENTORY DATA)and combined it with the libraries it required, after all, it was in multiple triggers which i find repulsive). i think getting rid of aids and implementing itemdex can decrease loading time further and maybe the performance of my map, as well.

i think we're getting a bit off-topic...but i don't actually have my own forum to discuss my tdht development in...lol. maybe i should make a new topic about this though, at any rate.
for now i should probably just post a reply in the uid thread about this and link from here to there http://www.thehelper.net/forums/showthread.php/146725-Units-Inventory-Data

 

[Dr Super Good]

Just look at the jass code it generates. Do you see any difference at all?

Vjass is bound by the same rules as normal JASS, it is not magic.

 

[SanKakU]

Just look at the jass code it generates. Do you see any difference at all?

Vjass is bound by the same rules as normal JASS, it is not magic.

do you mean export the map script? yeah i see the difference.
is there some other way to look at the code it generates?


whatever the case, 20 seconds is 20 seconds.

 

[Dr Super Good]

Look at the map trigger script, its normal JASS...

 

[PurgeandFire]

You can check the map script just by typing:

globals
    a b
endglobals

That will bring up and error and show all the source code. So just type in integer array fun[50] and then below it integer array fun. I am 100% positive that there is no difference. It is a vJASS feature that only has an effect if the size provided is 8192+. If it is less, then it will do nothing.

Also, a quote from the manual:

Global arrays might sometimes require more index space, jasshelper introduces syntax for sized arrays, it serves two purposes: It will allow you to request more space, and it also allows you to place a .size field on global arrays.

http://www.wc3c.net/vexorian/jasshelpermanual.html#storarray

It is only for more space and enables the .size feature. (but that just simply reads the size you defined it with) The loading speed reduction must have been from something else.

 

[SanKakU]

i always assumed when it said that that it meant leaving no indication of size meant that the size would be handled by jasshelper. in other words, jasshelper makes it so you don't have to constantly increase the array size just because in future updates you needed to increase it.

 

[Dr Super Good]

i always assumed when it said that that it meant leaving no indication of size meant that the size would be handled by jasshelper. in other words, jasshelper makes it so you don't have to constantly increase the array size just because in future updates you needed to increase it.

Sorry but that made no sense at all...

All WC3 arrays are arraylists with 2^13 indicies maximum bound.

 

[SanKakU]

isn't that what i said? if 8000 indicies is overkill, why not shorten the number? shouldn't it make the map speedier somehow if applicable? so...^ means the next number is an exponent huh? i didn't know. haha. there are a lot of math things like that that i don't know.

 

[PurgeandFire]

isn't that what i said? if 8000 indicies is overkill, why not shorten the number?

As DSG said:

Vjass is bound by the same rules as normal JASS, it is not magic.

Arrays do exist in normal JASS. Adding a bound [] does not shorten the number of slots it allocates. That feature of vJASS is to allow higher input for array indexes. However, it does not do magic or anything like that. It all gets converted to normal JASS.

globals
        integer array defined_size[50]
        integer array no_defined_size
    endglobals

Outputs as:

globals
// processed:         integer array defined_size[50]
integer array no_defined_size

//JASSHelper struct globals:
integer array s__defined_size

endglobals

That simply brings the global down. However, nothing else happens to the global.

This, on the other hand:

    globals
        integer array defined_size[10000]
        integer array no_defined_size
    endglobals

Outputs:

globals
// processed:         integer array defined_size[10000]
integer array no_defined_size

//JASSHelper struct globals:
integer array s__defined_size
integer array s__2defined_size

endglobals


function sg__defined_size_get takes integer i returns integer
    if(i<8191) then
        return s__defined_size[i]
    else
        return s__2defined_size[i-8191]
    endif
endfunction

function sg__defined_size_set takes integer i,integer v returns nothing
    if(i<8191) then
        set s__defined_size[i]=v
    else
        set s__2defined_size[i-8191]=v
    endif
endfunction

That basically duplicates the variable for more storage.

When you do something like this:

integer array defined_size[50]

It does not change anything. Even if you do use an index outside of the boundary:

    set defined_size[6732] = 52

It will still work. The thing to get from all this is that arrays will always have a maximum boundary of 8192, nothing will change how it is treated.