Refine docs.

doc/src/start/builds/minimal.md

@@ -17,6 +17,16 @@ opt-level = "z"     # optimize for size
 ```
 
 
+Use `i32` Only
+--------------
+
+For embedded systems that must optimize for code size, the architecture is commonly 32-bit.
+Use [`only_i32`] to prune away large sections of code implementing functions for other numeric types
+(including `i64`).
+
+If, for some reason, 64-bit long integers must be supported, use [`only_i64`] instead of [`only_i32`].
+
+
 Opt-Out of Features
 ------------------
 
@@ -28,13 +38,17 @@ Omitting arrays ([`no_index`]) yields the most code-size savings, followed by fl
 ([`no_float`]), checked arithmetic/script resource limits ([`unchecked`]) and finally object maps and custom types ([`no_object`]).
 
 Where the usage scenario does not call for loading externally-defined modules, use [`no_module`] to save some bytes.
-Disable script-defined functions ([`no_function`]) only when the feature is not needed because code size savings is minimal.
+Disable script-defined functions ([`no_function`]) when the feature is not needed.
+Both of these have little code size savings.
 
 
 Use a Raw [`Engine`]
 -------------------
 
 [`Engine::new_raw`](#raw-engine) creates a _raw_ engine.
-A _raw_ engine supports, out of the box, only a very [restricted set](#built-in-operators) of basic arithmetic and logical operators.
+A _raw_ engine supports, out of the box, only a very [restricted set]({{rootUrl}}/engine/raw.md#built-in-operators)
+of basic arithmetic and logical operators.
+
 Selectively include other necessary functionalities by loading specific [packages] to minimize the footprint.
+
 Packages are sharable (even across threads via the [`sync`] feature), so they only have to be created once.

doc/src/start/builds/performance.md

@@ -7,14 +7,17 @@ Use Only One Integer Type
 ------------------------
 
 Some features are for performance.  For example, using [`only_i32`] or [`only_i64`] disables all other integer types (such as `u16`).
+
 If only a single integer type is needed in scripts - most of the time this is the case - it is best to avoid registering
-lots of functions related to other integer types that will never be used.  As a result, performance should improve.
+lots of functions related to other integer types that will never be used.  As a result, [`Engine`] creation will be faster
+because fewer functions need to be loaded.
 
 
 Use Only 32-Bit Numbers
 ----------------------
 
 If only 32-bit integers are needed - again, most of the time this is the case - using [`only_i32`] disables also `i64`.
+
 On 64-bit targets this may not gain much, but on some 32-bit targets this improves performance due to 64-bit arithmetic
 requiring more CPU cycles to complete.
 
@@ -24,4 +27,5 @@ Minimize Size of [`Dynamic`]
 
 Turning on [`no_float`], and [`only_i32`] makes the key [`Dynamic`] data type only 8 bytes small on 32-bit targets
 while normally it can be up to 16 bytes (e.g. on x86/x64 CPU's) in order to hold an `i64` or `f64`.
+
 Making [`Dynamic`] small helps performance due to better cache efficiency.

doc/src/start/builds/wasm.md

@@ -14,8 +14,40 @@ But anyhow, do it because you _can_!
 When building for WASM, certain features will not be available, such as the script file API's and loading modules
 from external script files.
 
-Also look into [minimal builds] to reduce generated WASM size.  As of this version, a typical, full-featured
-Rhai scripting engine compiles to a single WASM file less than 200KB gzipped. When excluding features that are
-marginal in WASM environment, the gzipped payload can be further shrunk to 160KB.
+
+Size
+----
+
+Also look into [minimal builds] to reduce generated WASM size.
+
+As of this version, a typical, full-featured Rhai scripting engine compiles to a single WASM file
+less than 200KB gzipped.
+
+When excluding features that are marginal in WASM environment, the gzipped payload can be
+further shrunk to 160KB.
+
+
+Speed
+-----
 
 In benchmark tests, a WASM build runs scripts roughly 1.7-2.2x slower than a native optimized release build.
+
+
+Common Features
+---------------
+
+Some Rhai functionalities are not necessary in a WASM environment, so the following features
+are typically used for a WASM build:
+
+|    Feature    | Description                                                                                                                                                                                                                      |
+| :-----------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`unchecked`] | When a WASM module panics, it doesn't crash the entire web app; however this also disables [maximum number of operations] and [progress] tracking so a script can still run indefinitely - the web app must terminate it itself. |
+| [`only_i32`]  | JavaScript has only one `number` type and we're only supporting `wasm32` here (so far).                                                                                                                                          |
+| [`no_module`] | A WASM module cannot load modules from the file system, so usually this is not needed, but the savings are minimal; alternatively, a custom [module resolver] can be provided that loads other Rhai scripts.                     |
+
+The following features are typically _not_ used because they don't make sense in a WASM build:
+
+|  Feature   | Why unnecessary                 |
+| :--------: | ------------------------------- |
+|  [`sync`]  | WASM is single-threaded.        |
+| [`no_std`] | `std` lib works fine with WASM. |