`vm.compileFunction(source)` is much slower than `new vm.Script(source)` #35375

SimenB · 2020-09-27T11:36:36Z

Version: v14.12.0
Platform: Darwin Simens-MacBook-Pro.local 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64
Subsystem: vm

What steps will reproduce the bug?

See https://github.com/SimenB/vm-script-vs-compile-function and run node index.js.

It's just yarn init -2 to fetch the bundled yarn v2 source code (to have a large JS file), then loading that into new Script and compileFunction 100 times and seeing how long it takes.

Running this prints the following on my machine (MBP 2018):

Running with Script took 50 ms
Running with compileFunction took 4041 ms

How often does it reproduce? Is there a required condition?

Every time

What is the expected behavior?

It should be comparably fast to pass source code into compileFunction as it is to pass it into new Script.

What do you see instead?

About 80x worse performance. It gets worse the larger the loop is, so I'm assuming it's "simply" some cached data so new Script avoids the hit of parsing the same code multiple times, as it's fairly constant regardless of loop iterations

Additional information

This might be the same as #26229.

As mentioned in #26229 (comment) we see a huge performance improvement in Jest if we switch from compileFunction to the "old" new Script approach. As also mentioned there, this might be "fixed" (or at least possible to solve in userland) by the seemingly stalled #24069?

The text was updated successfully, but these errors were encountered:

SimenB · 2020-09-28T08:47:54Z

I added a quick and dirty produceCachedData, and it went down to about 180 ms. Which is a great improvement, albeit still 5x slower than new Script. And harder to manage (I'd prefer the implicit caching of the new Script APIs)

devsnek · 2020-09-28T18:17:23Z

cc @nodejs/v8, this might not be something fixable on node's side.

bnoordhuis · 2020-09-29T13:40:22Z

This is about v8::ScriptCompiler::CompileFunctionInContext() not using the code cache, right?

I don't think that's V8's issue to fix. V8 can't know whether it's safe to use the cache because the argument names and context extensions affect how the function is parsed.

Not that it's easy for Node.js. options.contextExtensions is a free-form list of mutable objects. Hard to cache on that unless object identity is good enough - but it probably isn't.

What Node.js (or perhaps V8) could optimize for is the presumably common case of no context extensions. TBD how to cache without introducing memory leaks.

SimenB · 2020-09-29T13:48:06Z

In Jest's case we'll be passing a different parsingContext all the time (Jest uses a different Context per test file for sandboxing), so if the cached data is dependent on the Context we'd probably still get a painful performance regression vs using vm.Script. If it's not possible to get caching based on the source code string (and the arguments) alone, we'll probably have to drop usage of compileFunction and stay on vm.Script.

Using the args array to vary the cache is no issue for our use case, though - 99% of the time they'll be the same, and for the cases it's not I guess it'd just create some more? Same as we have today with the manual function(some, args) {USER_SOURCE_CODE_HERE} wrapper we add which changes its source code via the arguments we pass in the manual function wrapper.

(That said, improving performance for compileFunction in the case of not passing parsingContext seems like a good thing even if it wouldn't be enough for Jest's use case 🙂)

bnoordhuis · 2020-09-29T14:04:35Z

If it's not possible to get caching based on the source code string (and the arguments) alone

I don't think that can work so you're probably better off sticking with vm.Script, yes. Argument names aren't insurmountable but context extensions are.

When you pass in context extensions, what's evaluated looks like this in pseudo code:

// assume a = { y: 42 } and b = { z: 1337 }
with (a)
  with (b)
    function f(x) {
      return x * y * z
    }

I say "pseudo code" but in fact it's really close to the runtime representation.

SimenB · 2020-09-30T14:47:49Z

@bnoordhuis reading your comment more closely, I see you're talking about contextExtensions. We don't use that, we use parsingContext - does that have the same limitations you think?

devsnek · 2020-09-30T14:57:40Z

I think this issue should be upstreamed.

rthreei · 2021-12-31T16:14:26Z

Fwiw, Node 16 has both Script and compileFunction performing similarly:

rishi vm-script-vs-compile-function % nvm use 14
Now using node v14.18.2 (npm v6.14.15)

rishi vm-script-vs-compile-function % node index.js
Running with Script took 51 ms
Running with compileFunction took 4379 ms
Running with compileFunction and cached data took 264 ms

rishi vm-script-vs-compile-function % nvm use 16
Now using node v16.13.1 (npm v8.1.2)

rishi vm-script-vs-compile-function % node index.js
Running with Script took 4280 ms
Running with compileFunction took 4350 ms
Running with compileFunction and cached data took 321 ms

devsnek · 2021-12-31T16:18:44Z

yes... in more recent versions of v8 the compilation cache is effectively broken. see v8:10284

SimenB · 2023-09-29T11:36:21Z

Just as a follow up here, these are the numbers I'm seeing with the latest 20.8 (nothing new, just posting to say it's still an issue).

$ nvm run 16.10 index.js
Running node v16.10.0 (npm v7.24.0)
Running with Script took 19 ms
Running with compileFunction took 1799 ms
Running with compileFunction and cached data took 145 ms

$ nvm run 16.11 index.js
Running node v16.11.1 (npm v8.0.0)
Running with Script took 1790 ms
Running with compileFunction took 1798 ms
Running with compileFunction and cached data took 147 ms

$ nvm run 20 index.js
Running node v20.8.0 (npm v10.1.0)
Running with Script took 1804 ms
Running with compileFunction took 1826 ms
Running with compileFunction and cached data took 141 ms

joyeecheung · 2023-09-29T12:26:27Z

I think we can at least not have any host-defined options at all when the importModuleDynamically isn't used. That should make it possible for the cache to get hit again in that case at least.

The performance hit would comeback again if you intent to support import() though, because until https://bugs.chromium.org/p/v8/issues/detail?id=10284 gets fixed, the host defined options is going to be serialized as part of the script, and since you might still want different host-defined options for different script even if they have the same source, V8 needs to reject the cache. The fix would be to either move the host defined options to somewhere more sensible (as proposed by the V8 issue initially), or as later comments in that issue suggested, just don't serialize it and provide some kind of callback for the embedder to compute the host-defined options (personally I'd prefer that, I think that provides more flexibility).

SimenB · 2023-09-29T12:45:18Z

Ooh, any workaround, even with caveats, would be awesome! 😃

The performance hit would comeback again if you intent to support import()

We do support that, but I believe that only happens if vm Modules are active (which is behind a flag)? If it's not behind a node flag, I'm happy to put it behind a Jest flag or some such so people who don't need it won't get the perf hit.

joyeecheung · 2023-09-29T13:02:30Z

I opened #49950 to address the "no import() needed" case which is a fairly simple change and can backport to earlier release lines (v20.x at least, not 100% sure about v18.x yet). Locally the in-isolate cache is getting hit again (I used the repro from OP but switched the script being compiled to test/fixtures/snapshot/typescript.js which is also big).

❯ ./node_main bench.js
Running with Script took 5428 ms
Running with compileFunction took 5332 ms
Running with compileFunction and cached data took 1010 ms

❯ ./node_pr bench.js
Running with Script took 56 ms
Running with compileFunction took 5369 ms
Running with compileFunction and cached data took 1013 ms

SimenB · 2023-09-29T13:04:57Z

Amazing! ♥️

SimenB · 2023-09-29T13:25:38Z

Can confirm the PR above works - gives these results on my machine with the repo from the OP

Running with Script took 20 ms
Running with compileFunction took 1804 ms
Running with compileFunction and cached data took 136 ms

It does seem I have to make sure to not pass in importModuleDynamically tho - I'll make sure to add a flag for that in Jest 30.

csvan · 2023-09-30T11:01:59Z

This is huge @joyeecheung ,thank you so much ❤️

rluvaton · 2023-09-30T18:17:25Z

So I did git bisect for v8 and the changes that cause this are v8 commit d2fd132bcbd4d069aacbe3ce7c8bb9bda93a7d88

I'll see what I can do

This makes it possile to hit the in-isolate compilation cache when host-defined options are not necessary. PR-URL: #49950 Refs: #35375 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>

Set a default host-defined option for vm.compileFunction so that it's consistent with vm.Script. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Users cannot access any API that can be used to return a module or module namespace in this callback without --experimental-vm-modules anyway, so this would eventually lead to a rejection. This patch rejects in this case with our own error message and use a constant host-defined option for the rejection, so that scripts with the same source can still be compiled using the compilation cache if no `import()` is actually called in the script. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

joyeecheung · 2023-10-21T07:29:03Z

So #50137 has landed, which means now if users compile a vm.Script with importModuleDynamically but without --experimental-vm-modules, the cache can still be hit if the code does not actually invoke import(). There are still some work that I think can be done:

The current way of "one callback (closure) per compilation call" doesn't seem to be really necessary for the use cases that I've seen. We should be able to provide a way for users to supply "one callback (closure) for a set of compilation call", thus allowing the set of calls sharing that callback (which needs one particular host-defined option) to hit the cache, even when import() is called and --experimental-vm-modules is used to implement a non-dummy importModuleDynamically.
Deal with the host defined options in the cache so that even the "one callback (closure) per compilation call" case can hit the cache i.e. address vm.compileFunction(source) is much slower than new vm.Script(source) #35375 (comment) - however this may not be that rewarding compared to the cost of the refactoring it needs in V8, I think 1 is still a nicer solution.
Regarding the specific issue reported by the OP - vm.compileFunction(source) is slow compared to new vm.Script(source), I think this is caused by the lack of support for in-isolation compilation cache of CompileFunction, and that seems to be implementatble (CompileFunction is a later-added V8 API for Node.js to address the "wrappers showing up in the debugger" problem, that's probably why support for in-isolation compilation cache was neglected). I am looking into implement that to bring the performance of vm.compileFunction(source) on par with new vm.Script(source) in repeated calls (also this should be useful to avoid the re-compilation cost in ESM detection mentioned in esm: detect ESM syntax in ambiguous JavaScript #50096 (comment)).

joyeecheung · 2023-10-21T17:39:39Z

WIP in https://chromium-review.googlesource.com/c/v8/v8/+/4962094 to add in-isolate compilation cache support to vm.compileFunction(), locally I get

❯ out/Release/node bench.js
Running with Script took 56 ms
Running with compileFunction took 55 ms
Running with compileFunction and cached data took 7 ms

If I change producedData: true to produceCachedData: cachedData === undefined (otherwise it's ~600ms because it then keeps serializing code cache even after the cache is produced on the first run, and the serialization comes with a cost).

Note that it still gives up on caching when context extensions are used as that can be much more complex to support. But I think context extensions are probably not used as often (we don't use it internally, at least).

About parsing context - I don't think it matters in terms of caching. The caching is done on context-independent scripts (which is why the cache is per-isolate, not per-context - context here being a V8 execution context, not a context for scope resolution which is actually part of the script). Binding to the context happens much later.

SimenB · 2023-10-21T18:36:03Z

Ooh, exciting! Using compileFunction simplifies the implementation in Jest quite a bit!

Set a default host-defined option for vm.compileFunction so that it's consistent with vm.Script. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Instead of using the public versions of the vm APIs internally, use the internal versions so that we can skip unnecessary argument validation. The public versions would need special care to the generation of host-defined options to hit the isolate compilation cache when imporModuleDynamically isn't used, while internally it's almost always used, so this allows us to handle the host-defined options separately. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Users cannot access any API that can be used to return a module or module namespace in this callback without --experimental-vm-modules anyway, so this would eventually lead to a rejection. This patch rejects in this case with our own error message and use a constant host-defined option for the rejection, so that scripts with the same source can still be compiled using the compilation cache if no `import()` is actually called in the script. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

This makes it possile to hit the in-isolate compilation cache when host-defined options are not necessary. PR-URL: nodejs#49950 Refs: nodejs#35375 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>

Set a default host-defined option for vm.compileFunction so that it's consistent with vm.Script. PR-URL: nodejs#50137 Refs: nodejs#35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Instead of using the public versions of the vm APIs internally, use the internal versions so that we can skip unnecessary argument validation. The public versions would need special care to the generation of host-defined options to hit the isolate compilation cache when imporModuleDynamically isn't used, while internally it's almost always used, so this allows us to handle the host-defined options separately. PR-URL: nodejs#50137 Refs: nodejs#35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Users cannot access any API that can be used to return a module or module namespace in this callback without --experimental-vm-modules anyway, so this would eventually lead to a rejection. This patch rejects in this case with our own error message and use a constant host-defined option for the rejection, so that scripts with the same source can still be compiled using the compilation cache if no `import()` is actually called in the script. PR-URL: nodejs#50137 Refs: nodejs#35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

This makes it possile to hit the in-isolate compilation cache when host-defined options are not necessary. PR-URL: #49950 Refs: #35375 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>

Set a default host-defined option for vm.compileFunction so that it's consistent with vm.Script. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Instead of using the public versions of the vm APIs internally, use the internal versions so that we can skip unnecessary argument validation. The public versions would need special care to the generation of host-defined options to hit the isolate compilation cache when imporModuleDynamically isn't used, while internally it's almost always used, so this allows us to handle the host-defined options separately. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Users cannot access any API that can be used to return a module or module namespace in this callback without --experimental-vm-modules anyway, so this would eventually lead to a rejection. This patch rejects in this case with our own error message and use a constant host-defined option for the rejection, so that scripts with the same source can still be compiled using the compilation cache if no `import()` is actually called in the script. PR-URL: #50137 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

karlhorky · 2023-11-12T13:12:29Z

I opened #49950 to address the "no import() needed" case which is a fairly simple change and can backport to earlier release lines (v20.x at least

Looks like @joyeecheung's #49950 and #50137 will be backported to Node.js v20 in the release v20.10.0:

v20.10.0 release proposal #50682

Previously there was no isolate compilation cache support for scripts compiled Script::CompileFunction() with wrapped arguments. This patch adds support for that. Refs: nodejs/node#35375 Change-Id: Id1849961ecd1282eb2dac95829157d167a3aa9a1

This makes it possile to hit the in-isolate compilation cache when host-defined options are not necessary. PR-URL: nodejs#49950 Refs: nodejs#35375 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>

Set a default host-defined option for vm.compileFunction so that it's consistent with vm.Script. PR-URL: nodejs#50137 Refs: nodejs#35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Instead of using the public versions of the vm APIs internally, use the internal versions so that we can skip unnecessary argument validation. The public versions would need special care to the generation of host-defined options to hit the isolate compilation cache when imporModuleDynamically isn't used, while internally it's almost always used, so this allows us to handle the host-defined options separately. PR-URL: nodejs#50137 Refs: nodejs#35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Users cannot access any API that can be used to return a module or module namespace in this callback without --experimental-vm-modules anyway, so this would eventually lead to a rejection. This patch rejects in this case with our own error message and use a constant host-defined option for the rejection, so that scripts with the same source can still be compiled using the compilation cache if no `import()` is actually called in the script. PR-URL: nodejs#50137 Refs: nodejs#35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Previously there was no isolate compilation cache support for scripts compiled Script::CompileFunction() with wrapped arguments. This patch adds support for that. Refs: nodejs/node#35375 Change-Id: Id1849961ecd1282eb2dac95829157d167a3aa9a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4962094 Reviewed-by: Camillo Bruni <[email protected]> Commit-Queue: Joyee Cheung <[email protected]> Cr-Commit-Position: refs/heads/main@{#91681}

This makes it possile to hit the in-isolate compilation cache when host-defined options are not necessary. PR-URL: #49950 Backport-PR-URL: #51004 Refs: #35375 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>

Set a default host-defined option for vm.compileFunction so that it's consistent with vm.Script. PR-URL: #50137 Backport-PR-URL: #51004 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Instead of using the public versions of the vm APIs internally, use the internal versions so that we can skip unnecessary argument validation. The public versions would need special care to the generation of host-defined options to hit the isolate compilation cache when imporModuleDynamically isn't used, while internally it's almost always used, so this allows us to handle the host-defined options separately. PR-URL: #50137 Backport-PR-URL: #51004 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Users cannot access any API that can be used to return a module or module namespace in this callback without --experimental-vm-modules anyway, so this would eventually lead to a rejection. This patch rejects in this case with our own error message and use a constant host-defined option for the rejection, so that scripts with the same source can still be compiled using the compilation cache if no `import()` is actually called in the script. PR-URL: #50137 Backport-PR-URL: #51004 Refs: #35375 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>

Original commit message: [compiler] support isolate compilation cache in CompileFunction() Previously there was no isolate compilation cache support for scripts compiled Script::CompileFunction() with wrapped arguments. This patch adds support for that. Refs: nodejs#35375 Change-Id: Id1849961ecd1282eb2dac95829157d167a3aa9a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4962094 Reviewed-by: Camillo Bruni <[email protected]> Commit-Queue: Joyee Cheung <[email protected]> Cr-Commit-Position: refs/heads/main@{#91681} Refs: v8/v8@f4b3f6e

This makes it possile to hit the in-isolate compilation cache when host-defined options are not necessary. PR-URL: nodejs#49950 Refs: nodejs#35375 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>

SimenB mentioned this issue Sep 27, 2020

jest 25 performance jestjs/jest#9457

Open

watilde added vm Issues and PRs related to the vm subsystem. performance Issues and PRs related to the performance of Node.js. labels Sep 28, 2020

SimenB mentioned this issue Oct 5, 2020

chore: drop usage of compileFunction jestjs/jest#10586

Merged

SimenB mentioned this issue Oct 24, 2020

Revert "Revert "vm: add importModuleDynamically option to compileFunction"" #35431

Merged

4 tasks

SimenB mentioned this issue Dec 31, 2021

[Bug]: Memory consumption issues on Node JS 16.11.0+ jestjs/jest#11956

Closed

SimenB mentioned this issue Jan 12, 2022

vm: add createCacheForFunction #24069

Closed

1 task

SimenB mentioned this issue Sep 13, 2023

module: rework of memory management in vm APIs with the importModuleDynamically option #48510

Closed

SimenB mentioned this issue Sep 29, 2023

v20.8.0 proposal #49932

Merged

joyeecheung mentioned this issue Sep 29, 2023

vm: use default host-defined options when importModuleDynamically is not set #49950

Merged

joyeecheung mentioned this issue Oct 12, 2023

vm: reject in importModuleDynamically without --experimental-vm-modules #50137

Closed

joyeecheung mentioned this issue Oct 21, 2023

esm: detect ESM syntax in ambiguous JavaScript #50096

Merged

This comment was marked as spam.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`vm.compileFunction(source)` is much slower than `new vm.Script(source)` #35375

`vm.compileFunction(source)` is much slower than `new vm.Script(source)` #35375

SimenB commented Sep 27, 2020 •

edited

Loading

SimenB commented Sep 28, 2020 •

edited

Loading

devsnek commented Sep 28, 2020

bnoordhuis commented Sep 29, 2020

SimenB commented Sep 29, 2020 •

edited

Loading

bnoordhuis commented Sep 29, 2020

SimenB commented Sep 30, 2020 •

edited

Loading

devsnek commented Sep 30, 2020

rthreei commented Dec 31, 2021

devsnek commented Dec 31, 2021

SimenB commented Sep 29, 2023 •

edited

Loading

joyeecheung commented Sep 29, 2023 •

edited

Loading

SimenB commented Sep 29, 2023

joyeecheung commented Sep 29, 2023

SimenB commented Sep 29, 2023

SimenB commented Sep 29, 2023 •

edited

Loading

csvan commented Sep 30, 2023

rluvaton commented Sep 30, 2023 •

edited

Loading

joyeecheung commented Oct 21, 2023 •

edited

Loading

joyeecheung commented Oct 21, 2023 •

edited

Loading

SimenB commented Oct 21, 2023

karlhorky commented Nov 12, 2023

This comment was marked as spam.

vm.compileFunction(source) is much slower than new vm.Script(source) #35375

vm.compileFunction(source) is much slower than new vm.Script(source) #35375

Comments

SimenB commented Sep 27, 2020 • edited Loading

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

SimenB commented Sep 28, 2020 • edited Loading

devsnek commented Sep 28, 2020

bnoordhuis commented Sep 29, 2020

SimenB commented Sep 29, 2020 • edited Loading

bnoordhuis commented Sep 29, 2020

SimenB commented Sep 30, 2020 • edited Loading

devsnek commented Sep 30, 2020

rthreei commented Dec 31, 2021

devsnek commented Dec 31, 2021

SimenB commented Sep 29, 2023 • edited Loading

joyeecheung commented Sep 29, 2023 • edited Loading

SimenB commented Sep 29, 2023

joyeecheung commented Sep 29, 2023

SimenB commented Sep 29, 2023

SimenB commented Sep 29, 2023 • edited Loading

csvan commented Sep 30, 2023

rluvaton commented Sep 30, 2023 • edited Loading

joyeecheung commented Oct 21, 2023 • edited Loading

joyeecheung commented Oct 21, 2023 • edited Loading

SimenB commented Oct 21, 2023

karlhorky commented Nov 12, 2023

This comment was marked as spam.

`vm.compileFunction(source)` is much slower than `new vm.Script(source)` #35375

`vm.compileFunction(source)` is much slower than `new vm.Script(source)` #35375

SimenB commented Sep 27, 2020 •

edited

Loading

SimenB commented Sep 28, 2020 •

edited

Loading

SimenB commented Sep 29, 2020 •

edited

Loading

SimenB commented Sep 30, 2020 •

edited

Loading

SimenB commented Sep 29, 2023 •

edited

Loading

joyeecheung commented Sep 29, 2023 •

edited

Loading

SimenB commented Sep 29, 2023 •

edited

Loading

rluvaton commented Sep 30, 2023 •

edited

Loading

joyeecheung commented Oct 21, 2023 •

edited

Loading

joyeecheung commented Oct 21, 2023 •

edited

Loading