Memory usage

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 low memory options). 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.

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 which are needed for strings, buffers, objects, object property tables, etc. Second, there are much fewer larger allocations needed for e.g. Ecmascript function bytecode, large strings and buffers, value stacks, the global string table, and the Duktape heap object.

For most systems memory usage or the memory allocation pattern is not an 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.

See low memory options and low-memory.rst for more discussion on what low memory features exists and how to tune the memory pools for low memory systems.