A GVar annyira jó, hogy ha több scripten (fs/gm) között szeretnél változókat tárolni, akkor abban egyszerûbb.
Ezen kívül teljesen felesleges használni, mivel nem támogat több adattípust, mint a PAWN.
Elméleti síkon ha a stacked elég nagy a tömbhöz, akkor rendben van. Mivel a PAWN compiler fordítása során a célplatformnak megfelelõen állítja be a \"cella\" méretét, ezért ez változni fog. A SAMP által használt PAWN fordító 32 bites platformra készült, tehát 1 cella 32 bit = 4 bájt.
Ennek megfelelõen az integer max 32 bites = 1 cellás lehet.
Tehát azon függvény kezeléséhez, amiben használod majd a változót, alsó hangon is 4000 cella = 16000 bájtnyi stack terület szükséges. Ez azt jelenti, hogy amint a függvény meghívódik, 16000 bájt (~ 15 kb) stack terület lefoglalódik, nagyobb scripteknél ezért ajánlatos, ha már van bekalibrált stack méret, a 4000 cellát HOZZÁADNI, ha még nincs, akkor úgy bekalibrálni, hogy a többszörösen beágyazott függvények esetében se fussál ki a stack területbõl, mert akkor szimplán ki fog fagyni a szerver.
Már alapból a függvény meghívása során pluszba adódnak a stackre rápakolt egyéb adatok (visszatérési pointer, stb.), így jön ki a Zsoleszka által leírt 4010 cella.

A fenti adatot úgy lehet kicsalni a fordítóból, hogy valami extrém kicsire állítod be a stack méretet a
 

#pragma dynamic [szám]

 
direktívával. A fordító minden olyan esetben kiírja a hibát, ha gyanítja, hogy a többszörösen beágyazott függvények esetén felmerülhet az a gyanú, hogy stack overflow történhet (ez gyk. azt jelenti, hogy a lentrõl felfele növekvõ stack belír az \"elõtte\" lévõ memóriába - ezt a SAMP szerver egy elegáns azonnali kilépéssel reagálja le).
Dinamikusan foglalja a memóriát: ez bajos. A dinamikus memóriával nagyon óvatosan kell bánni. Kicsi figyelmetlenség és lesz egy rohadt nagy memórialyuk (vagy ki tudja, hogy hívják ezt magyarul, memory leak) a SAMP szerveredben. Ezt így kell érteni:
 

RandomFuggveny()
{
   for(new i=0; i<5000; i++)
   {
      SetGVarInt(\"teszt\",i,i);
   }
}
main()
{
   RandomFuggveny();
   return 1;
}

 
A fenti kód hibája, hogy a lefoglalt memóriát nem szabadította fel a heap-bõl, ezzel okozva egy \"memórialyukat\", mely a szerver futásáig megmarad. Nyilván, ha ez a memórialyuk egy többször használatos függvényben fordul elõ, akkor minden egyes meghíváskor elszivárog ez a memóriamennyiség, elõbb utóbb kifogyva a lehetséges memóriából. Még a világklasszis programokban (khm, Windows, khm, Firefox) is nem egy ilyen hiba van, és ha õk elkövetik, te is el fogod.
A változók maguk nem foglalnak helyet a PAWN kódban, mivel a PAWN csak a változó helyére mutató pointert raktároz el (amennyiben a változó globális). Lokális változók esetén pedig a \"fájlnövekedés\" annyi, hogy pár bájttal több az assembly kód (hiszen 0x0FA0 több, mint mondjuk 0x64, az elõbbi csak 2 bájtba fér be).
A felhasznált memória, amennyiben a tömböket lokálisan [függvényen belül] akarod használni, csak addig lesz nagy, amíg a függvény futása zajlik. A függvény visszatérése után a stackrõl lepakolódik a változó és a változó miatt lefoglalt memória, önmagától (ezért a dinamikus memória esetén leírt memóriaszivárgás nem probléma).
Az elérés sebessége lassabb lesz (ez az ún. \"overhead\" miatt van, a pluginban elérhetõ függvények lefuttatása több idõbe telik), DE a plugin kevesebb memóriát fog enni, hiszen annyit foglalsz csak le, amennyi kell.
Fontos továbbá, hogy a GVar plugin (szándékosan) nem támogat komplexebb adatstruktúrákat, ha valami olyat szeretnél, akkor muszáj lesz a stack változókat használni.
Elméleti síkon egyébként a maximális tömbhossz az, ami egy cellát teljesen túltölt (4 bájt), de ezt nyilván nem fogod elérni, mivel annyi kocsit az életbe nem fogsz lerakatni a SAMP-pal.

Az elérés sebessége, ahogyan te is leírtad, lassabb pluginnal (amit leírtál, abból én azt veszem ki, hogy erre a konklúzióra jutottál).
A memória, pedig ahogy leírtam, csak akkor lesz kevesebb, ha pont annyit foglalsz le, amennyi kell neked. Ha egy 20 slotos szerón éppen csak 5-en vannak, akkor nem kell a maradék 15 blokkot létrehozni. A plugin futtatása eleve memóriát eszik, de a lefoglalt memória mértékét jobban lehet optimalizálni a pluginnal. Ennek az ára a fenti \"memóriaszivárgás\": egy apró figyelmetlenség és hamar kifagyhat a szerver.

A memóriaszivárgás a következõ:
a dinamikusan lefoglalható memória azért dinamikusan lefoglalható, mert egy adott hosszúságú memóriaszakaszt lefoglalhatsz saját használatra az ún. \"heap-bõl\" (az most lényegtelen, hogy mi, ha érdekel, elmondom). A memóriaszakasz hosszát nem kell meghatároznod futtatás elõtt, elég futtatás alatt. Ettõl \"dinamikus\". A memóriaszakaszt azonban, amennyiben a használat után nem szabadítod fel, keletkezik egy \"lyuk\"  -- azaz a memória, amit lefoglaltál, elveszik: hisz nem szabadítottad fel.
Pl. ha egy függvényben 2 kb memóriát lefoglalsz, de a függvény végeztével nem szabadítod fel, minden egyes alkalommal, mikor a függvény lefut, 2kb memória el fog veszni. Ez elõbb utóbb a memória kikezdésével fog járni.
Az a memória, amit lefoglaltál a ciklusoddal, ott marad a samp szerver névterébe, mivel a használat után nem szabadítottad fel. Az, hogy önmagában mennyi memóriát eszik a plugin, könnyû kideríteni: fogd a plugint, és indítsd el egy tök üres scripttel, nézd meg, mennyit foglal. Ha már magától is sokat foglal, akkor mérlegelni kell, hogy hosszú távon megtérülhet-e a használata.
A memóriaszivárgás nem akkora nagy probléma a GVar pluginnal, mivel a változóknak van id-jük és nevük, de pl. egy C++-ban ha a függvényben, amiben lefoglaltad a memóriát, nem szabadítod fel, akkor elveszik a mutató a memóriára, tehát egy végleges vesztésrõl beszélünk.
Amit meg kell jegyezni: a dinamikus memória esetén TE kezeled azt, hogy mennyit foglalsz le, és mennyit szabadítasz fel. Ha nem szabadítod fel, akkor a memória ott fog maradni a szerver névterében, használatlanul, addig, míg le nem állítod azt.

Jól gondolod. Az én véleményem az (volt, és marad is), hogy PAWN esetében nem igazán érdemes használni semmiféle dinamikus memórián alapuló dolgot. Alapjában véve konstans dolgok tárolásához meg még annyira sincs értelme.
Ha tényleg, tényleg szeretnél dinamikus memória allokációt, és nincs szükséged a scriptek közti elérésekre, van rá egy y_malloc nevû függvénykönyvtár, Y_Less írta a C-s malloc/alloc/free függvények alapján. Elvileg gyorsabb és mivel alap PAWN, nem plugin, ezért gyk. 0 memóriafogyasztással rendelkezik.
De, mint mondtam, alapjában, fõleg egy házrendszer adataihoz, fölösleges dinamikusan lefoglalható memória.