Node.js: Some quick optimization advice
medium.com
Node.js: Some quick optimization advice
1–10 of 75 posts
Re: Node.js: Some quick optimization advice
#2Wow, the v8 optimizer can sometimes be a pretty blunt instrument. Shouldn't it look at the size of the inlined function after it compiles it to some intermediate state that erases things like comments and names?
Re: Node.js: Some quick optimization advice
#3Wow, the v8 optimizer can sometimes be a pretty blunt instrument. Shouldn't it look at the size of the inlined function after it compiles it to some intermediate state that erases things like comments and names?
Such a state does not exist inside V8. Things happen as they are parsed. Since V8 has no idea what a piece of JS will do until it gets all the context, it has to use a silly thing like character count to perform inlining. It could create an intermediate state, but that would require a code overhaul that would likely slow down the entire thing anyway.
If I had to suggest a change, I would use the 600-char count as a starting point for one-time functions, and then count the number of calls to a function, counting how many instructions it produces (basically tossing an incrementing variable into the compilation state, and storing it per Function object).
But then again, I've never played with the inside of V8, only the outside. I consider myself lucky to be in that position, because V8 is pretty dang sweet.
Re: Node.js: Some quick optimization advice
#4If you're wondering why comments are a factor at all, and aren't just discarded by the lexer, remember that comments in JS are preserved and available to things like `Function.prototype.toString()`. I've seen this used to do evil multiline string support a few times. Slap the multiline string or template into a comment inside a function and then have another function that toStrings it and strips the boilerplate.
This sounds like a horrifying hack but it's also pretty similar to how Angular's shorthand DI works.
Re: Node.js: Some quick optimization advice
#5The bug has been marked as WontFix by the V8 team: https://code.google.com/p/v8/issues/detail?id=3354. It looks like they are considering fixing it for TurboFan and not for Crankshaft, but I'm not sure what that means. Does that only apply to asm.js code?
Re: Node.js: Some quick optimization advice
#6So, is this is a point in favor of not commenting your Javascript code or using inline docs?
Historically, I preferred to use inline JsDoc style comments as the source of documentation for my public APIs. Recently though, I decided that I didn't like them and that I wanted something better. I was hoping to find some tool that parses my JS to AST, figures out what was being exported (e.g. what was public) and writes a JSON document that I could diff over time, to figure out what was documented and what wasn't (in my external docs). So far, I have found this project called `doctor` which sounded close to what I'm looking for, but it still relies on comments ~ https://github.com/jdeal/doctor ~ So, I might have to write it myself using something like Esprima to get the AST...
Re: Node.js: Some quick optimization advice
#7The bug has been marked as WontFix by the V8 team: https://code.google.com/p/v8/issues/detail?id=3354 . It looks like they are considering fixing it for TurboFan and not for Crankshaft, but I'm not sure what that means. Does that only apply to asm.js code?
I think Turbofan aims to supersede Crankshaft, but gradually.
Re: Node.js: Some quick optimization advice
#8I had this exact thing happen to me. It drove me crazy. Thank you!
Re: Node.js: Some quick optimization advice
#9Posted that yesterday, didn't get much traction.
Whenever I begin to convince myself that JS and Node are actually fine languages / environments to code on, some weird edge case like this pops up.
Not entirely sure if it's just its popularity, which is bound to expose its rough corners, or if it's fundamentally bad designed (written in 10 days in the late 90's, etc)
Re: Node.js: Some quick optimization advice
#10If you're wondering why comments are a factor at all, and aren't just discarded by the lexer, remember that comments in JS are preserved and available to things like `Function.prototype.toString()`. I've seen this used to do evil multiline string support a few times. Slap the multiline string or template into a comment inside a function and then have another function that toStrings it and strips the boilerplate. This…
> This sounds like a horrifying hack (...) how Angular's shorthand DI works.