|
|
|
In zMUD, all scripts were "interpreted". This means that every script command was parsed into commands and arguments and then executed. In the example:
#LOOP 1000 {a=%i}
the "a=%i" command was parsed and then executed each time around the loop. "Parsing" involves splitting the text into a command name and parameters, then looking up the variables (@a in this case) and any commands.
This is actually very inefficient. In the above example, zMUD looks up the "@a" variable reference 1000 times!
CMUD has a completely different scripting engine that is compatible with zMUD. However, the big difference is that scripts in CMUD are compiled to an intermediate "byte code" which is then cached and executed.
This is similar to how modern languages such as Java work and happens completely behind the scenes.
In the above example, the script is compiled as needed. Each time through the loop, the "a=%i" statement has already been compiled into code that looks something like this:
Code: |
LOOPVAR 0
VARASSIGN 1 |
where "LOOPVAR" and VARASSIGN" are just text representations of integer command codes. In this case, the variable reference has been converted to the code "VARASSIGN 1" which means "store the value in variable 1". The "A" variable name has been compiled into the database record index for the variable.
Executing this byte code is *much* faster than re-parsing and re-looking up the @a variable each time around the loop. Even in this simple case, CMUD is about 30% faster than zMUD. And this is even with the zMUD optimized hashing lookup for variables and when no other variables or settings are defined that might slow things down.
As the script command becomes more complicated, the compiler provides better speed benefits. So even though CMUD uses database technology to provide better data integrity and has more overhead than zMUD, it is still faster than zMUD is most all cases because of the compiler.
Common Compiler Questions
- Can I turn off the compiler?
- No. The compiler is always used in the background to improve performance. There is no reason to turn if off.
- What if I make a change to my script? How does it get recompiled?
- Whenever a change is made to a script or other setting (trigger, alias, etc) CMUD sets a flag to tell it to compile the script before the next time it is used. This slightly slows down the next execution of the script, but the time needed to compile a script is very small, so you'll rarely notice the difference. CMUD can always compile and execute a script faster than zMUD could parse it and execute it.
- Can I force it to recompile a script or trigger?
- Not at this time. The compiler is automatic and transparent and will recompile as needed, but otherwise will used the cached compiled byte code to speed up execution. You really don't need to mess with the details.
- Can I store my compiled scripts or send them to a friend?
- No. Compiled scripts are only stored internally to improve performance. They are never stored externally. When your scripts are loaded, they are compiled in the background as needed, and this compiling is very fast and not noticeable. You cannot exchange compiled scripts with friends. You would never want to run a compiled script from a 3rd party because there would be no way to look at the source code to see if the script was going to do something bad.
- My script runs slower in CMUD than in zMUD!
- Even though the compiler almost always generates code that is much faster than the zMUD parser, there still might be situations that are not optimized where the CMUD database overhead makes it slower than zMUD. Just keep in mind that with CMUD you are getting better data integrity (no corrupted settings files like was common in zMUD) and more features. It's often possible to change your script to use newer features in CMUD (such as Local Variables) to make your scripts much faster than zMUD.
Also, anytime you use the #EXEC or %exec commands, you are bypassing the normal compile procedure and forcing a string to be compiled and executed at runtime, which is usually slower.
|
|