Difference between revisions of "String Parsing Optimization"

Revision as of 04:30, 27 November 2013

String Parsing is a powerful language for designing content on the Flexible Survival MUD. The language permits read functions, write functions, and allows users to create dynamic content based on a combination of those functions. Its semantics were originally designed by Damaged and later rewritten by Fauna for increased performance.

String Parsing, like other markup languages, does cause a hit in performance when inserted into plain text. This article exists to provide solutions for those seeking to squeeze the most performance out of their code. It will not tell you how to write clean or legible code, NOR will it teach you the fundamental markup of String Parsing. For information on those subjects, see the wiki article on String Parsing and review the in-game manual.

Performance: Why should I care?

Performance is important for a number of reasons.

Optimized code reduces the perceived latency of navigation in a MUD. Doing so should be enjoyable on even the most sluggish of connections.

Optimized code reduces the Flexible Survival server load, thus permitting us to provide more and more detailed user-visible content.

Optimized code reduces the memory cost of programs and #dbrefs. In the case of a fatal memory spike or other unforeseen circumstances, the chances of services ceasing function are reduced when baseline memory is kept to a reasonable minimum.

How does this relate to String Parsing?

String Parsing is a markup language found throughout many aspects of the game. From transformation messages, to sex scenes, to exploration, to NPC interaction, and more, String Parsing is the gold standard for ensuring high quality content with minimal perceived latency and maximum ease of deployment. Despite this, we must keep an eye on our code to ensure continued high quality submissions and end-user satisfaction.

Strictly speaking, a more important language to keep optimized is the MUF backend that Flexible Survival is based upon. However, since this guide is targeted at a general audience and not Mucker-level or higher staff, String Parsing tips and tricks will be the subject matter I'll focus on.

For the subsequent sections, please use the in-game @viewparse command to indent and colorize markup for heightened legibility.

[if ] statements

[if ] statements are the heart, brain, and skeletal structure of the String Parsing body.

[if ][end if] Mistakes

A basic [if ][end if] statement is prone to some syntactic errors, but little in terms of optimization woes.

Always use the template [if [target] is <gender>] when checking for a target's gender. Do not use [if [target] = <gender>]. Despite taking less space in the grand scheme of things, the 'is' function is specifically optimized for checking a target's gender.

[if [target] = <gender>]

[if [target] is <gender>]

Do not check for integers with the '=' sign. This is a function designed to check a string. Use '==' instead. Thirty minutes benchmarking with Fauna has shown that checking directly for an integer is both faster and cleaner.

[if stat cocks of [target] = 1]

[if stat cocks of [target] == 1]

Avoid not statements when possible. For example, [if time is not night] is the same as [if time is day].

[if time is not night]

[if time is not day]

[if time is day]

[if time is night]

[if ][else][end if] Mistakes

[else] creates potential for redundancy if a coder is not paying attention. Here is a small before-and-after list of sentences, followed by clear instruction.

[if time is winter]The large bear returned to his cave to hibernate.[else]The small fox jumped over the fence.[end if]

The [if time is winter]large bear returned to his cave to hibernat[else]small fox jumped over the fenc[end if]e.

In the above example, repeated text has been removed from the [if ] statement itself and added as prefix and suffix to the code, respectively. This provides the exact same user-visible output with less characters and processing requirements.

A woman in tight jeans and an unassuming blouse [if time is night]would normally [end if]man[if time is day]s[end if] the counter.[if time is day] She's twirling a pen in her fingers, seemingly disinterested in her body of work.[else] However, she doesn't appear to be here right now.[end if]

A woman in tight jeans and an unassuming blouse [if time is day]mans[else]would normally man[end if] the counter. [if time is day]She's twirling a pen in her fingers, seemingly disinterested in her body of work[else]However, she doesn't appear to be here right now[end if].

A woman in tight jeans and an unassuming blouse [if time is day]mans the counter. She's twirling a pen in her fingers, seemingly disinterested in her body of work[else]would normally man the counter. However, she doesn't appear to be here right now[end if].

In the above example, I've illustrated a two-step series of optimizations.

First step: Move a repeated space at the beginning of the final [if ][else][end if] statement. Move repeated periods in that same statement to the end. Merge two independent [if ][end if] statements into a singular [if ][else][end if] statement.

Second step: Determine whether to simplify the overall parsing. In this case, two separate [if ][else][end if] statements can be merged into one.

Protip: Saving memory is more important with our as-of-writing server configuration (11.26.2013) than performance. If splitting up an [if ][else][end if] to two [if ][end if] statements results in any significant reduction of characters, feel free to do so.

This document is a work in progress and is thus subject to change. All views and opinions expressed in here are solely Songbird's. Please only modify with either A), explicit permission to do so, or B), a fix for known factual inaccuracy / grammar errors.