Task: preprocessing built-in javascript
r...@tinyclouds.org
occasionally post little tasks to the mailing list. If you do this,
please create a patch against HEAD and post it to this mailing list.
I'll wait a week for someone to do them before doing it myself :)
You might have noticed a bunch of debug() calls sprinkled about
src/node.js and other core code. Because our debugging options are so
few, this is one of the few ways of inspecting what the program is
doing (especially when error reporting breaks!). Here is an example
of debug() being used:
http://github.com/ry/node/blob/9e8afe9133f18382e787fd84a405f04990259d3e/src/node.js#L520
And here is its definition
(http://github.com/ry/node/blob/9e8afe9133f18382e787fd84a405f04990259d3e/src/node.js#L341-348)
var debugLevel = 0;
if ("NODE_DEBUG" in process.env) debugLevel = 1;
function debug (x) {
if (debugLevel > 0) {
process.stdio.writeError(x + "\n");
}
}
Pretty simple stuff.
The problem is that these debug calls are not free to make. Even when
the environmental variable is not present node will execute those
function calls - that is they actually slow down execution.
The task is to remove these calls with the preprocessor in the non-debug build.
All javascript is compiled into the node binary as C-strings and it is
done with this utility, borrowed from V8
http://github.com/ry/node/blob/d96c52694a56e10f2ba5db239680cb6a0af02120/tools/js2c.py
The JS2C already supports MACROS - so it should just be a matter of
figuring out how to use it properly. I suspect this requires a bit of
python and a bit of javascript knowledge and would take a couple of
hours to complete.
Zoka
Have look at patch at http://gist.github.com/337907
It will eliminate debug(x) statements from src/node.js and lib/*.js
for release build
Zoka
On Mar 19, 8:42 pm, r...@tinyclouds.org wrote:
> For fun and to attract people to hacking Node, I'm going to
> occasionally post little tasks to the mailing list. If you do this,
> please create a patch against HEAD and post it to this mailing list.
> I'll wait a week for someone to do them before doing it myself :)
>
> You might have noticed a bunch of debug() calls sprinkled about
> src/node.js and other core code. Because our debugging options are so
> few, this is one of the few ways of inspecting what the program is
> doing (especially when error reporting breaks!). Here is an example
> of debug() being used:
>
> http://github.com/ry/node/blob/9e8afe9133f18382e787fd84a405f04990259d...
>
> And here is its definition
> (http://github.com/ry/node/blob/9e8afe9133f18382e787fd84a405f04990259d...)
>
> var debugLevel = 0;
> if ("NODE_DEBUG" in process.env) debugLevel = 1;
>
> function debug (x) {
> if (debugLevel > 0) {
> process.stdio.writeError(x + "\n");
> }
> }
>
> Pretty simple stuff.
>
> The problem is that these debug calls are not free to make. Even when
> the environmental variable is not present node will execute those
> function calls - that is they actually slow down execution.
>
> The task is to remove these calls with the preprocessor in the non-debug build.
>
> All javascript is compiled into the node binary as C-strings and it is
> done with this utility, borrowed from V8http://github.com/ry/node/blob/d96c52694a56e10f2ba5db239680cb6a0af021...
Ryan Dahl
> Hi Ryan,
>
> Have look at patch at http://gist.github.com/337907
> It will eliminate debug(x) statements from src/node.js and lib/*.js
> for release build
>
> Zoka
Zoka, nice!
Instead of writing out that marcos file, it would be nice to just have
src/macros.py and pass a value to it indicating whether it's a debug
built or not. JS2C supports this.
Zoka
javascript files and macros definition file that must be named
macros.py
macros.py extension is bit misleading, since it is more or less
replacement for C style header file that is parsed by JS2C.
Have a look deps/v8/src/macros.py - it only contains constants and
macros definitions.
Am I missing something obvious?
On Mar 20, 6:34 am, Ryan Dahl <coldredle...@gmail.com> wrote:
Ryan Dahl
> As far as I could see JS2C supports only 2 types of files:
> javascript files and macros definition file that must be named
> macros.py
>
> macros.py extension is bit misleading, since it is more or less
> replacement for C style header file that is parsed by JS2C.
> Have a look deps/v8/src/macros.py - it only contains constants and
> macros definitions.
> Am I missing something obvious?
Oh true. Okay, I want to avoid writing out a macros file - I'd rather
have it included as a standalone file. Do you agree? (I could be
convinced otherwise.) What if we have src/macros-default.py and
src/macros-debug.py, each used for their respective builds.
Zoka
Since debug and release build are processed together, it means that we
would have to have src/debug/macros.py and src/default/macros.py, but
it looks a bit funny.
Other possibility is to just supply macros file for default (release)
build, and not to supply it for debug build at all, however this is
asymmetrical and does not allow for future expansion.
On Mar 20, 8:19 am, Ryan Dahl <coldredle...@gmail.com> wrote: