návod [YSI] Velikost AMX po kompilaci [*] #6

[Scydo 397]

YSI4 VELIKOST AMX PO KOMPILACI #6
*****

Zdravím vás u dalšího návodu práce s YSI. Dnešní díl bude spíše jen takové kecání o teorii, s kterou má snad každý troufalí začátečník problém. A jeden z takových je i tady(že ano Carloosi), a jelikož jde o dalšího uživatele, co nedá pokoj, dokud nedostane co chce, i když mu každý jasně naznačuje, že to prostě není ještě pro něj, tak jsem byl jaksi nucen udělat tento návod.

Jak mnoho z vás ví, tak YSI(od verze 3.0) je obrovská skoro(ano skoro) zcela includově mezi sebou propojená knihovna. Protože po kompilaci si bere některé potřebné údaje i z jiných includů, které uživatel ani nechtěl nahrát, proto je výsledný kompilovaný soubor tak velký. Ale, co z pár řádků a jednoho nahraného includu způsobí, že kompilovaný soubor je až v několika MB?
Všude je odpověď zcela prostá. Ve starších verzích(od 3.1 a méně) za to mohli samotní uživatelé, jelikož hned ze začátku nahrávali soubor, který obsahoval nahrání skoro všech uživatelných includů(y_ini, y_commands, y_colors, y_foreach...) a to sice pomocí:

#include <YSI>

Pak není divu, že ano, když nahráváte přes 40 includů a z něj využijete možnosti jen z jediné, že má až přes 4MB, že ano?
Nojo, ale jak to je s novější verzi a to 4.0+? To zase záleží na několika faktorech:

• 1) Na verzi používané knihovny - to jsem zmiňoval právě před chvilkou, že verze 3.1 měla dokonce i soubor, kde se načítali zcela skoro všechny includy z knihovny najednou. Verze 4.0 už ale má tzv. "alternativní načítání" což načte jen daný potřebný include(y_commands, y_timers, y_hooks...), a nemusí někde se tamhle propojovat například s y_races.
  

  /* Staromódní načítání(+ještě z verze 3.1): 
  lze takto načítát i s verzí 4+ ale doporučuji jen na rychlé ověřující práce */
  #include <YSI\y_ini>
  #include <YSI\y_commands>
  #include <YSI\y_colors> 
  
  /* Alternativní a doporučené načítání(od verze 4) */
  #include <YSI_Storage\y_ini>
  #include <YSI_Visual\y_commands>
  #include <YSI_Server\y_colors> 
  /* a tak dále */

• 2) Použité includy z knihovny - některé includy mají více možností, které Y_Less nebo autoři neuveřejňují, jelikož jde spíše o systémové fce, callbacky, proměnné a tak dále, které slouží spíše pro knihovnu, než pro uživatele. A právě velká většina includů obsahuje tyhle věci "navíc", které se prostě do kompilace přidají. Samozřejmě, také záleží, jak uživatel pracuje s tou knihovnou(viz. bod 4).
• 3) Zpracování kódu - Optimalizace, optimalizace a zase jen optimalizace. Způsobem, jaký uživatel pracuje s knihovnou tak ovlivňuje obsah po kompilaci, jelikož YSI se v několika případech snaží "zachránit" obsah tím, že buď tam něco přidá, a nebo prostě spadne kompiler. K tomu může dojít hodně způsoby například nedostatečnou znalostí teorie samotného pawn, zbytečné bloky navíc, šílené pole, nadměrný počet použitých fcí, špatné hookování... Kód, který uživatel zpracovává musí být maximálně "čistý" jak jen to je možné(přehlednost, bez zbytečných proměnných, vkládat návratové hodnoty jen tam kde jsou nutné, hlídat si podmínky, operátory)... A hlavně v žádném případě nemíchejte knihovnu s nějakým jiným podřadným includem. UŽ VŮBEC NE DINI NEBO DCMD. Ne jen, že je to naprostí kktina, ale taky tím zcela zmarníte tu krásnou rychlost a optimalizaci knihovny(kromě sscanf2, který snad spolupracuje všude se vším). Ani i-zcmd a podobné rychlejší includy na příkazy apod. jelikož pak ztratíte další možnosti toho daného includu(y_commands) například přidávat alternativní příkazy, přidávat je jen pro danou skupinu a tak dále. Zde je menší ukázka dobře optimalizovaného a skoro(dokonalost samozřejmě nejde, najde se pokaždé lepší) "čistý" zpracovaný kód s využitím YSI4:
  

  #include <YSI_Core\y_utils>
  #include <YSI_Data\y_iterate>
  #include <YSI_Coding\y_timers>
  #include <YSI_Coding\y_hooks>
  #define MAX_TIPS (10)
   
  new
          Iterator: Tips<MAX_TIPS>,
          Tip_Text[MAX_TIPS][145], Tip_Color[MAX_TIPS];
   
  void:Tip_Add(color, const text[]) {
   
          new
              Tip_ID = Iter_Free(Tips);
          strcpy(text, Tip_Text[Tip_ID]);
          Tip_Color[Tip_ID] = color;
          Iter_Add(Tips, Tip_ID);
  }
   
  hook OnScriptInit() { defer Tip_Timer();return (true);}
  hook OnScriptExit() { stop Tip_Timer(); Iter_Clear(Tips);return (true);}
   
  timer Tip_Timer[1000*60*3]() {
   
          new
                  Tip_ID = Iter_Random(Tips);
          SendClientMessageToAll(Tip_Color[Tip_ID], Tip_Text[Tip_ID]);
  }

• 4) Práce s knihovnu - Tohle se spíše týká uživatelů. Jak jsem již zmínil uživatel má neskutečný vliv na výsledné AMX. Každá vychytávka YSI má nějaké pro i proti. Proto, když nejsou zcela nutné dané includy používat, tak je nepoužívejte, ani možnosti v nich. Například tagy v y_ini:
  

  new INI: Sbr = INI_Open("sbr.txt");
  INI_SetTag(Sbr, "Hrac");
  INI_WriteInt(Sbr, "AdminLevel", ...);
  INI_WriteInt(Sbr, "Level", ...); 
  INI_WriteInt(Sbr, "Deaths", ...);
  INI_WriteBool(Sbr, "IsVip", ...);
  INI_Close(Sbr);

  K čemu přidávat tagy, když tam vkládáte jenom odstavec údajů a konec. Vůbec to nějak netřídíte. Sice je to jen poznámka, která nám zrovna nepřidá MB, ale to je jen pro příklad. Nebo v y_timers. Hodně lidí má nutnost používat defer, nebo ptask. Ale o žádné extra rozdíly nejde. Bez problémů lze používat i obyčejné timer.

INCLUDY Z KNIHOVNY, KTERÉ NEJČASTĚJI ZVYŠUJÍ VELIKOST KOMPILOVANÉHO SOUBORU NA MB:
(upozornění: Zvyšují jen v případě špatného používání knihovny!)

y_ini
y_commands
y_timers
y_groups
y_dialog
y_inline
y_ac
y_td
y_areas
y_text
y_master
y_lock /* (YSIv4 při nahrávání způsobí pád kompileru!) */
y_language
y_debug /* (při použití dlevelu 10) */
y_user
y_races /* (uživatel musí pro používání přidat správné preprocesory!) */
y_properties /* (ten ani nefunguje, nepoužívat!) */

Na závěr bych rád dodal: jestliže pracujete s YSI a mezi problémy patří error cannot read from file: "internal\y_version" , neustále padá kompiler či kompilovaný soubor je stejně v MB, tak YSI není pro vás a přejděte raději na dof2, i-zcmd apod. Jinak velice doporučuji YSI4(/4.1).

Jinak, děkuji za přečtení, a že už to daný uživatelé konečně pochopí. V případě, že jsem se někde sekl, něco mám špatně, nebo blbě vysvětlené... je to zcela možné, tak napište. Stejné v případě, že máte nějaké dotazy.

[ATomas 286]

Co se tyce velikosti amx, tak je to tak trochu i vina autora (Y_Less), protoze spravne by to melo byt delane tak, ze by funkce meli byt (pokud to lze) delane pres stock (tzn pokud neni pouzit do kompilovaneho amx souboru se funkce nezahrne) a #if defined (napr pro promene, pokud je potreba je (ne)pouzit).

 

Ale to je spis univerzalni postoj, YSI kdym nikdy nepouzival (pawn umim, takze nepotrebuji to pouzivat ), je mozne ze tam jsou veci (napr public kvuli timerum), ktere ani jinak napsat nelze.

Edited 26. Červenec, 2016 by ATomas

[Scydo 397]

Co se tyce velikosti amx, tak je to tak trochu i vina autora (Y_Less), protoze spravne by to melo byt delane tak, ze by funkce meli byt (pokud to lze) delane pres stock (tzn pokud neni pouzit do kompilovaneho amx souboru se funkce nezahrne) a #if defined (napr pro promene, pokud je potreba je (ne)pouzit).

Ony také jsou dělané přes stock. Za tu velikost můžou převážně preprocesory, protože tam je preprocesor snad na všechno. Na velikost řetězce, na počet ukládání, na počet maximálně možných použití id příkazů, počet tagů, max tagů, velikost tagů, nejmenší možná velikost tagů... to má pomalu více pojistek než možností nemluvě o proměnných, emitu...

 

Ale to je spis univerzalni postoj, YSI kdym nikdy nepouzival (pawn umim, takze nepotrebuji to pouzivat ), je mozne ze tam jsou veci (napr public kvuli timerum), ktere ani jinak napsat nelze.

Ono YSI obsahuje i varianty, které jsou dokonce rychlejší a efektivnější než v samotném pawn. Samozřejmě, to je na uživateli. Když bude používat default, nic se neděje.