Difference between revisions of "Optimizing Plugins (AMX Mod X Scripting)"

From AlliedModders Wiki
Jump to: navigation, search
(Introduction)
(Tips and Tricks)
Line 1: Line 1:
 
LOL HAX
 
LOL HAX
  
==Tips and Tricks==
+
LOL HAX
===Lookup Tables===
 
Precompute what can be precomputed.  For example, say you have a mapping of weapon indices to names:
 
<pawn>if (weapon == CSW_AK47)
 
  copy(name, len, "weapon_ak47")</pawn>
 
Ignoring the fact that we have <tt>get_weapon_name</tt> in [[AMX Mod X]], this is inefficient.  We could precompute this result in a table:
 
<pawn>new g_WeaponNamesTable[TOTAL_WEAPONS][] = {
 
  //..0 to CSW_AK47-1
 
  "weapon_ak47",
 
  //..CSW_AK47+1 to TOTAL_WEAPONS-1
 
};</pawn>
 
 
 
===Perfect Hashing===
 
:TODO: explain this
 
 
 
 
 
===Local Strings===
 
The [[Pawn]] compiler does not optimize the DATA section, which stores all hardcoded strings and global arrays.  If you reference the same hardcoded string 500 times in your plugin, it will appear 500 different times.  If this seems bad enough, it actually does this with all strings.  For example, the empty string ("") appears everywhere in the include files, usually used as a default parameter to many natives.  This too is copied into the data section for each unique reference. 
 
 
 
For example:
 
<pawn>set_cvar_string("amx_gaben", get_cvar_string("amx_gaben") + 1)</pawn>
 
This will create two copies of "amx_gaben" in the DATA section.  While this doesn't really hurt, it does increase the size of your plugin. 
 
 
 
Similarly, this has the same problem:
 
<pawn>#define AMX_GABEN "amx_gaben"
 
set_cvar_string(AMX_GABEN, get_cvar_string(AMX_GABEN) + 1)</pawn>
 
The only way to avoid this mess is to use global variables.  As stated earlier, they're basically free storage.
 
<pawn>new AMX_GABEN[] = "amx_gaben"
 
set_cvar_string(AMX_GABEN, get_cvar_string(AMX_GABEN) + 1)</pawn>
 
 
 
Again, while not necessary, this will reduce your plugin's size in memory and on disk.  If you're already using defines, you can make this switch easily.
 
 
 
In order to prevent this from changing, you may want to declare it constant:
 
 
 
<pawn>new const AMX_GABEN[] = "amx_gaben"
 
set_cvar_string(AMX_GABEN, get_cvar_string(AMX_GABEN) + 1)</pawn>
 
 
 
Now it is a perfectly safe method of storage.
 
  
 
==Faster Natives==
 
==Faster Natives==

Revision as of 19:38, 17 January 2007

LOL HAX

LOL HAX

Faster Natives

AMX Mod X replaces many of the old AMX Mod natives with faster versions. Read below to discover them.

Cvar Pointers

As of AMX Mod X 1.70, you can cache "cvar pointers". These are direct accesses to cvars, rather than named access. This is a critical optimization which is dozens of times faster. For example:

new g_enabled = register_cvar("csdm_enabled", "1")
//OR
new g_enabled = get_cvar_pointer("csdm_enabled")
 
stock SetCSDM(num)
   set_pcvar_num(g_enabled, num)
 
stock GetCSDM()
   return get_pcvar_num(g_enabled)

All of the cvar* functions (except for set_cvar_string) are mapped to [get|set]_pcvar_*. You can get a cached cvar pointer with get_cvar_pointer() or register_cvar().

FormatEX

As of AMX Mod X 1.70, there is an ultra high-speed version of format() called formatex(). It skips copy-back checking, unlike format(). formatex() cannot be used if a source input is the same as the output buffer. For example, these are invalid:

new buffer[255]
formatex(buffer, 254, "%s", buffer);
formatex(buffer, 254, buffer);
formatex(buffer, 254, "%d %s", buffer[2]);

It should be noted that format() will behave the same as formatex() if it detects that there will be no copy-back needed. However, formatex() does not check this, and thus is slightly faster for situations where the coder is sure of its usage.

File Writing

As of AMX Mod X 1.70, there are new natives for file writing. Read_file and write_file are O(n^2) functions for consecutive read/writes. fopen(), fgets(), fputs(), and fclose() are O(n) (or better) depending on how you use them.