| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
what's going on here? accidental debug or something else, same with the return 0 below.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, accidental debug.
Sorry, something went wrong.
|
would we consider shipping the binary for this, with a more node-specific name than js2c-cache? |
Sorry, something went wrong.
|
We don't need to ship this anywhere, it is run during build time. |
Sorry, something went wrong.
There was a problem hiding this comment.
Looking at the definition of NativeModule.wrap 12 lines up - how is cached_data being used?
Sorry, something went wrong.
There was a problem hiding this comment.
It isn't, I'm in the process of making it work.
Sorry, something went wrong.
There was a problem hiding this comment.
@indutny oh oops - sorry for the noise!
Sorry, something went wrong.
|
@indutny so you figure that if anyone wants to make use of this kind of functionality outside of lib/*.js, like NW.js, they'll be using source and hacking Node a bit anyway? |
Sorry, something went wrong.
|
@rvagg I haven't thought about it that far yet, and so far I'm not sure if it provides any significant speed boost after all. Need to finish it up to do benchmarks. |
Sorry, something went wrong.
|
Alright, I think the PR is ready now. Let's see what CI (especially ARM bots) think about it: https://ci.nodejs.org/job/node-test-pull-request/1314/ |
Sorry, something went wrong.
|
@rvagg regarding NW.js, there is a cached_data option for vm.ContextifyContext, so I guess they could try using it and obtaining this data through the js2c-cache. |
Sorry, something went wrong.
|
Data point, when I experimented with the preparser API a while ago (what corresponds to kProduceParserCache now) I saw no change in start-up times whatsoever. Vyacheslav later told me it only makes a difference when the source code is 100s or 1000s of kilobytes big. Ours is in the low 100s but it's not loaded all at once. |
Sorry, something went wrong.
|
@bnoordhuis it seems that my small require benchmark disagrees with you... |
Sorry, something went wrong.
There was a problem hiding this comment.
Style nit: we prefer camel case for JavaScript variables no?
Sorry, something went wrong.
There was a problem hiding this comment.
Ack.
Sorry, something went wrong.
|
@bnoordhuis also, it is not exactly preparser thing. It is caching compiled code, not parser data. |
Sorry, something went wrong.
|
Yes, I get that. I'm curious to see if it makes a real difference. Full-codegen is pretty quick but maybe not on ARM. |
Sorry, something went wrong.
There was a problem hiding this comment.
Everywhere else nullptr is used. Is it okay to use NULL here?
Sorry, something went wrong.
There was a problem hiding this comment.
Ack.
Sorry, something went wrong.
|
Looks like this js2c-cache does not compile on windows. Going to skip it for now, and iterate towards it sometime later (if I'll have any incentive). |
Sorry, something went wrong.
|
New CI: https://ci.nodejs.org/job/node-test-pull-request/1315/ (Previous is mostly green, except windows). |
Sorry, something went wrong.
There was a problem hiding this comment.
Unused function?
Sorry, something went wrong.
There was a problem hiding this comment.
Ack.
Sorry, something went wrong.
|
Gosh, one more windows failure. Should be fixed now. |
Sorry, something went wrong.
Sorry, something went wrong.
|
Sorry for the ignorance, but can this impact the speed of userlandrequire`s? Those can be a big problem in larger projects and if it's possible giving users the ability to cache if NODE_ENV is production would be a huge help. |
Sorry, something went wrong.
|
Pushed fix, new CI: https://ci.nodejs.org/job/node-test-pull-request/1323/ |
Sorry, something went wrong.
|
@benjamingr possibly no, fs overhead is very likely to be bigger than compilation overhead, but this PR opens new APIs for using code cache in ChildProcess. |
Sorry, something went wrong.
|
New CI with windows support: https://ci.nodejs.org/job/node-test-pull-request/1327/ (hopefully) |
Sorry, something went wrong.
|
One more fix, and it should be good to go: https://ci.nodejs.org/job/node-test-pull-request/1329/ |
Sorry, something went wrong.
There was a problem hiding this comment.
Perhaps use subprocess.Communicate to simplify? (written without testing)
output, error = p.communicate(input=line)
return output
Sorry, something went wrong.
There was a problem hiding this comment.
Appears to be working locally, thank you for suggestion.
Sorry, something went wrong.
|
Last CI was finally green. Please let me know if it LGTY. |
Sorry, something went wrong.
Introduce `cachedData`/`produceCachedData` options for `v8.Script`. Could be used to consume/produce V8's code cache for speeding up compilation of known code. PR-URL: nodejs#4777 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
|
@hashseed Sound crazy, Do you mean use v8 as the vm platform for any language that can compile to this "reverse engineered byte code"? A bit of the overlapping to wasm, but I believe js bytecode has more feature than low level wasm |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Use V8 Code caching when host_arch == target_arch. This commit may
slightly improve startup time, and definitely improves require times
(when doing many of them).
For example, executing following file:
var fs = require('fs'); var http = require('http'); var https = require('https'); var path = require('path'); var util = require('util');Takes: ~74ms on master
Takes: ~54ms with this commit
Number were taken on OS X with 64-bit node.js binaries.
cc @nodejs/collaborators @nodejs/v8