expose the bytecode in cli

[gengjiawen]

This will make debug and performance more easily

v8

MonkeyLang

[bnoordhuis]

You already can, kind of - it's the -D1 flag to qjs (JS_SetDumpFlags in quickjs.h)

[gengjiawen]

You already can, kind of - it's the -D1 flag to qjs (JS_SetDumpFlags in quickjs.h)

qjs -D1 t2.js no output on my side (version: ng 0.8.0). I am directly use the release binary, should I build my own or something I miss ?

[bnoordhuis]

You'll need a debug build (no -DNDEBUG)

[gengjiawen]

Any chance this is moves into production build by default. Consider it's under a flag, won't drag down perf in normal mode.

[saghul]

Some of the debug flags may have an impact if enabled in release builds.

[bnoordhuis]

Any chance this is moves into production build by default. Consider it's under a flag, won't drag down perf in normal mode.

Probably not because it embiggens the library by quite a bit. One of quickjs's design goals is being able to run in constrained environments so we're mindful of size.

[chqrlie]

Enabling all the trace/dump facilities does cause a slow down even if the flags are not enabled via a command line option or a call to JS_SetDumpFlags(). PR #770 is underway to control these features and expose the flags, but we should probably investigate an intermediary approach where selected features are compiled that do not affect performance but give the developper access to the byte code: the ability to output the byte code or more generally give enough access for debugging should be available separately.

[gengjiawen]

Probably not because it embiggens the library by quite a bit. One of quickjs's design goals is being able to run in constrained environments so we're mindful of size.

In real cases in embedder we can always turn it off. But we need perf insight during development, which is my real case.

[saghul]

Can't you use a Debug build for that?

[gengjiawen]

Can't you use a Debug build for that?

That's what I do for now. But I want this make it to the default build. Sometimes I want to do the diff with latest qjs binary in release page.

[saghul]

We would need to separate the bytecode dumping logic from the other dump flags I guess...

[gengjiawen]

We would need to separate the bytecode dumping logic from the other dump flags I guess...

How should we push this forward. Is currently turn on ENABLE_DUMPS in release mode can be considered ?

[saghul]

No because that turns on some other stuff that is too impactful.

Perhaps the bytecode dumping ifdefs can simply go away.

Feel free to give it a try in a PR and we can take it from there.

[gengjiawen]

I deployed a qjs debug build on http://k2.gengjiawen.com:8001/quickjs

One thing I notice is that

• it lacks bytecode length like v8 have
• have a extra eval in final bytecode

[chqrlie]

The bytecode dumping routines and the corresponding tables should be controlled by a specific define in addition to NDEBUG. eg:

     js_free(ctx, fd);
 }

-#ifdef ENABLE_DUMPS // JS_DUMP_BYTECODE_*
+#if defined ENABLE_DUMPS || defined JS_DUMP_BYTECODE
 static const char *skip_lines(const char *p, int n) {
     while (p && n-- > 0 && *p) {