-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
try compiling for sm 102 #4305
Closed
Closed
try compiling for sm 102 #4305
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nickva
force-pushed
the
spidermonkey-102
branch
from
December 13, 2022 17:14
f56155f
to
aa73f3b
Compare
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 16, 2023
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 16, 2023
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 16, 2023
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Looks like 3x faster than SM 1.8.5 and 4x faster than SM 91. For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 16, 2023
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 19, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 20, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 31, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 31, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 31, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 31, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 31, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Mar 31, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Apr 1, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Apr 2, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Apr 2, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Apr 2, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Apr 10, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Apr 10, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
Apr 17, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
12 tasks
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
May 21, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
May 23, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
May 24, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
May 25, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
to nickva/couchdb
that referenced
this pull request
May 25, 2023
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see apache#4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see apache#4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST trasform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there.
nickva
added a commit
that referenced
this pull request
Apr 23, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
Apr 25, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 1, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 1, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 6, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 6, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 6, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 6, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 6, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 6, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 10, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 10, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 11, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 12, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 12, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 12, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 12, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 13, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 13, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 13, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 13, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 13, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 13, 2024
https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448
nickva
added a commit
that referenced
this pull request
May 15, 2024
Some benefits over Mozilla Spidermonkey: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already [1]. * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so [2]. * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448 [1] #4154 [2] #4305
nickva
added a commit
that referenced
this pull request
May 15, 2024
Some benefits over Mozilla Spidermonkey: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already [1]. * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so [2]. * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448 [1] #4154 [2] #4305
Closing in favour of #5314 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
My local from source build of SM 102 doesn't work with 91 instruction so used Ronny's Git Actions build, which worked great.
There were a few changes to the API which sadly means another copy and past of the whole C++ API bits which makes it hard to see the changes. The main changes I noticed is
SClassOps
struct got smaller by one member and csp_allows gets an extra flag.However during test runs I started getting
TypeError {}
so that's how far I got only.