From 0f080e5fdf469bdf8699f6967bb1a9b8096246c9 Mon Sep 17 00:00:00 2001
From: Sami Vaarala <sami.vaarala@iki.fi>
Date: Sat, 24 Oct 2015 17:47:55 +0300
Subject: [PATCH] Website drafting for ROM builtins

---
 website/guide/memoryusage.html | 22 ++++++++++++++--------
 website/index/index.html       |  7 ++++---
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/website/guide/memoryusage.html b/website/guide/memoryusage.html
index 44cda345..5ac585c2 100644
--- a/website/guide/memoryusage.html
+++ b/website/guide/memoryusage.html
@@ -1,13 +1,17 @@
 <h1 id="memoryusage">Memory usage</h1>
 
 <p>Duktape allocates memory on demand and doesn't require a pre-allocated heap.
-When you create a heap on a 32-bit system, Duktape needs about 46kB for the
-built-in Ecmascript objects (about 22kB with
-<a href="#memory-constrained-options">low memory options</a>).  Additional
-memory is then allocated as needed for executing application scripts.
-Reference counting ensures there is very little unused allocated memory, the
-only exception being objects which participate in reference loops; these are
-collected eventually by mark-and-sweep.</p>
+When you create a heap on a 32-bit system, Duktape needs about 70kB for the
+built-in Ecmascript objects.  With specific
+<a href="#memory-constrained-options">low memory options</a> initial memory
+usage is about 27kB.  This can be further reduced to about 3kB when moving
+built-in objects and strings to ROM (read-only data section).  It's also
+possible to move custom native bindings fully into ROM.</p>
+
+<p>After heap creation additional memory is then allocated as needed for
+executing application scripts.  Reference counting ensures there is very
+little unused allocated memory, the only exception being objects which
+participate in reference loops; these are collected eventually by mark-and-sweep.</p>
 
 <p>The memory allocations needed by Duktape fall into two basic categories.
 First, there are a lot of small allocations between roughly 16 to 128 bytes
@@ -21,7 +25,9 @@ issue.  On low memory environments, e.g. less than 1MB of system RAM, you may
 want to use a custom allocator to optimize memory usage.  A pool-based
 allocator deals well with the small allocation churn without fragmentation
 issues.  The downside is that you need to tune the memory pool sizes to match
-the concrete allocation patterns.</p>
+the concrete allocation patterns.  You may want to use a pool allocator or a
+hybrid allocated if the platform allocation primitives perform poorly with
+a lot of small allocations.</p>
 
 <p>See <a href="#memory-constrained-options">low memory options</a> and
 <a href="https://github.com/svaarala/duktape/blob/master/doc/low-memory.rst">low-memory.rst</a>
diff --git a/website/index/index.html b/website/index/index.html
index 77bed227..28397bd3 100644
--- a/website/index/index.html
+++ b/website/index/index.html
@@ -59,12 +59,13 @@ Duktape API to call Ecmascript functions from C code and vice versa.</p>
 <h1>Code and RAM footprint</h1>
 <table>
 <tr><td>&nbsp;</td><td>x86 default</td><td>x86 lowmem</td><td>x86 full lowmem</td></tr>
-<tr><td>Code</td><td>224kB</td><td>198kB</td><td>234kB</td></tr>
-<tr><td>Startup RAM</td><td>70kB</td><td>43kB</td><td>28kB</td></tr>
+<tr><td>Code</td><td>224kB</td><td>198kB</td><td>234kB</td></tr>  <!-- FIXME: to be updated -->
+<tr><td>Startup RAM</td><td>70kB</td><td>43kB</td><td>3kB</td></tr>
 </table>
 
 <p>Full <a href="https://github.com/svaarala/duktape/blob/master/doc/low-memory.rst">lowmem</a>
-uses "pointer compression", Node.js Buffer and typed array support enabled.</p>
+uses "pointer compression" and ROM-based strings/objects.  ROM-based strings/objects can
+also be used without other low memory options.</p>
 
 <h1>Current status</h1>
 <ul>