Hercules C++ pxCore / Duktape integration - Memory usage tests

For the Hercules client, we are going to be doing some work that involves a couple of their drawing technologies, name "pxCore" and "pxScene".  The links below offer a lot more details on these particular technologies.  pxCore is a C++ graphics library that is used on a wide variety of embedded devices that the client distributes.  pxscene is a wrapper application around pxCore that exposes the drawing APIs to Javascript through Node and V8.

The client is concerned that Node and V8 are too "heavy" for their low-powered embedded devices.  To this end, we have been working at integrating duktape (http://duktape.org/) into pxScene, replacing Node. This has gone well.

Pxscene

Pxscene is a platform independent drawing platform / app that will be used on a wide variety of embedded devices for the Hercules client.  You can find more information here, and you can download the app to be used for testing: http://www.pxscene.org/

The code for pxCore / pxscene is available in Github here:

Build instructions can be found here:  https://github.com/pxscene/pxCore/blob/master/examples/pxScene2d/README.md

Step-by-step instructions to build the existing duktape integration on Ubuntu 16.04 can be found here:

https://github.com/topcoderinc/pxCore/blob/duktape_proof_of_concept/step-by-step-duktape-linux-build.md���

-DUSE_DUKTAPE is deprecated (not used)....  Instead, we added two new cmake switches SUPPORT_NODE and SUPPORT_DUKTAPE.  Both are enabled by default.  The app now looks for a file called .sparkUseDuktape in the home directory to enable duktape.

You can validate the engine used through the "about.js" example (just type "about.js" in the address bar of pxScene).  It will list the engine - either Node or duktape.

Requirements

In our previous challenge (winning submission in the forum), we looked at memory usage and if we could tweak duktape directly to use a bit less memory.  We also documented where the memory was going when Javascript files are run in Duktape.

For this challenge, we are going to expand that investigation to try some of Duktape's features for memory reduction and see:

* What the effect is on memory usage
* What the effect is on pxscene functionality

There are a number of different options documented here:

https://github.com/svaarala/duktape/blob/master/doc/low-memory.rst���

These include:

• DUK_USE_AUGMENT_ERRORS
• DUK_USE_TRACEBACKS
• DUK_USE_VERBOSE_ERRORS
• DUK_USE_VERBOSE_EXECUTOR_ERRORS
• DUK_USE_PC2LINE
• DUK_USE_LEXER_SLIDING_WINDOW
• DUK_USE_JSON_STRINGIFY_FASTPATH
• DUK_USE_JSON_QUOTESTRING_FASTPATH
• DUK_USE_JSON_DECSTRING_FASTPATH
• DUK_USE_JSON_DECNUMBER_FASTPATH
• DUK_USE_JSON_EATWHITE_FASTPATH
• DUK_USE_BUFFEROBJECT_SUPPORT
• DUK_USE_JX
• DUK_USE_JC
• DUK_USE_ES6_OBJECT_SETPROTOTYPEOF
• DUK_USE_ES6_OBJECT_PROTO_PROPERTY
• DUK_USE_ES6_PROXY
• DUK_USE_REGEXP_SUPPORT
• DUK_USE_BYTECODE_DUMP_SUPPORT
• DUK_USE_DEBUG_BUFSIZE
• DUK_USE_LIGHTFUNC_BUILTINS
• DUK_USE_REFERENCE_COUNTING
• DUK_USE_DOUBLE_LINKED_LIST
• DUK_USE_REFCOUNT16
• DUK_USE_STRHASH16
• DUK_USE_STRLEN16
• DUK_USE_BUFLEN16
• DUK_USE_OBJSIZES16
• DUK_USE_HSTRING_CLEN
• DUK_USE_HEAPPTR16
• DUK_USE_HEAPPTR_ENC16
• DUK_USE_HEAPPTR_DEC16

We want to investigate these flags and determine which ones can / can't be used for pxscene and which ones help with the memory usage.

Documentation

For the profiling documentation, we want to run the fancy.js example and capture memory profile information.  You can also test with a "real" application here:

http://showcase-prototype.herokuapp.com/

That URL should load into pxscene and show a keyboard browseable UI that we are building.

For the config flags, we want to know:

* If def'ing or un-def'ing a flag helps with memory usage
* If def'ing or un-def'ing a flag breaks pxscene

Target

You can find the target branch here:  https://github.com/pxscene/pxCore/tree/_duktape2

Deliverables

A document describing each memory flag and the impact on pxscene, both from a memory standpoint and a usability standpoint.  Note that the more information you provide here the better.

You should also describe, in detail, how the flags were applied and tested.  The reviewers will need to reproduce your results, so your documentation needs to be clear on how you tested and determined the output.

Review Goals

For review, we want reviewers to double check the results seen above to make sure they make sense and are reproducible.