Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js: Some quick optimization advice

medium.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Node.js: Some quick optimization advice

#31

Post by to3m »

tambourine_man wrote: post #9

Posted 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)

I don't think it's fair to blame something like this on Javascript per se, but that doesn't mean it isn't fundamentally badly designed ;) However, people actually appear to have started to notice this, and the latest result, ECMAScript 6, looks actually like it might be OK. At last, when people tell you JS isn't that bad, you can actually believe them - though if they told you that before, maybe do your own research too.

With the latest version, you have block scope, you have a shorthand function syntax, the "this" nonsense is teeny bit less awful, there's help at hand for the inevitable callback chains, and strict mode is still there. There's also a new class syntax (though actually - aside from "this"! - I thought the old-style classes were the least of its problems).

I won't apologise for rolling my eyes a bit at how it's taken until ver 6 to get block scope, but better late than never.

Re: Node.js: Some quick optimization advice

#32

Post by nikolay »

xlm1717 wrote: post #13
tambourine_man wrote: post #9

Posted 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)

>written in 10 days in the late 90's Netscape browser has not been used in a long time, and JS has been standardized as ECMAScript since the late 90's.

"Standardized" does not equate "good" though. ECMAScript is a very confused language that keeps borrowing from other languages and turns itself into a mess. Not to mention that "Universal JavaScript" is an oxymoron as most real-world JavaScript (well, ECMAScript) is not supported by major browsers and developers need to use things like Babel and the likes. And I don't see an end to it.

Re: Node.js: Some quick optimization advice

#33

Post by hyperpape »

chrisseaton wrote: post #18
spullara wrote: post #2

Wow, 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?

Are you sure that the size of the intermediate representation is a good indication of suitability to inline? I think we'd be replacing one arbitrary heuristic with another. If we wanted to do really well we'd look at the cost of the actual operations in both the caller and callee, and reason about how they interact with inlining and things like that, but that's a bottomless pit of a problem and by then the user has b…

Hotspot and V8 serve very different niches, but doesn't Hotspot use the size of the bytecode for this decision?

(Or rather, that's the first step of deciding. It will inline larger methods if they're sufficiently hot).

Re: Node.js: Some quick optimization advice

#34

Post by draperp »

STRML wrote: post #19
untog wrote: post #15

Earlier quoted context omitted.

As others have said, you can always strip comments in production builds. But I agree that this is utterly silly - I'd like to see a movement to deprecate including comments in parsing at all. Anything that makes use of such a feature is hacky weirdness from the start.

Function.prototype.toString() should be deprecated anyway. There are very few to no legitimate uses of it that are any better than awful eval() hacks. Re: this comment, if you just don't make huge comments inside the body, but rather above it - as is the usual standard - this is less of an issue.

Every JS dependency injection framework that I've ever seen uses it.

Re: Node.js: Some quick optimization advice

#36

Post by dap »

fla wrote: post #27
dap wrote: post #16

This is a microbenchmark. It's a tight loop that calls the function 500 million times. The function itself just adds two numbers. It's pretty close to the best possible improvement for inlining a function. If that's what your program does, and it's a big part of what your program does, then inlining it may be a big performance win. Even then, addressing this may not be a worthwhile tradeoff. Even then, as others have…

I think the oddity here is that the function length takes the comments into account.

Agreed that's interesting (in a mostly academic sense), but the thrust of the post is about using that fact to make choices in writing code, and there's an awful lot of discussion here about that idea. That's what I was addressing.

Re: Node.js: Some quick optimization advice

#37

Post by spullara »

chrisseaton wrote: post #18
spullara wrote: post #2

Wow, 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?

Are you sure that the size of the intermediate representation is a good indication of suitability to inline? I think we'd be replacing one arbitrary heuristic with another. If we wanted to do really well we'd look at the cost of the actual operations in both the caller and callee, and reason about how they interact with inlining and things like that, but that's a bottomless pit of a problem and by then the user has b…

True, just a better heuristic (Hotspot uses it). Not clear that with javascript you have time to do a better job. Even if it was done in the parser I think you could make a better size counter that didn't include comments and names.

Re: Node.js: Some quick optimization advice

#38

Post by abritinthebay »

nikolay wrote: post #32
xlm1717 wrote: post #13

Earlier quoted context omitted.

>written in 10 days in the late 90's Netscape browser has not been used in a long time, and JS has been standardized as ECMAScript since the late 90's.

"Standardized" does not equate "good" though. ECMAScript is a very confused language that keeps borrowing from other languages and turns itself into a mess. Not to mention that "Universal JavaScript" is an oxymoron as most real-world JavaScript (well, ECMAScript) is not supported by major browsers and developers need to use things like Babel and the likes. And I don't see an end to it.

> a very confused language that keeps borrowing from other languages and turns itself into a mess

I could describe almost any language that builds on previous language idioms like this. C++, most of the later Lisps, Java for sure, C# especially, Objective-C certainly... etc.

You're assuming your conclusion then trying to prove it with personal opinion.

Re: Node.js: Some quick optimization advice

#39

Post by mhd »

One comment mentions a quite significant speedup when switching the variable initialization step of the for loop from let to var. As excepted, you'll also get this if you keep the "let" keyword, but move it outside of the loop.

What kind of optimization step is prevented here?

Re: Node.js: Some quick optimization advice

#40

Post by netcraft »

clessg wrote: post #22
pauljz wrote: post #4

If 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…

> I've seen this used to do evil multiline string support a few times. Love me some FOAM: https://github.com/foam-framework/foam/blob/master/apps/todo... .

es6 template literals will be a godsend for stuff like this. but thats particularly ugly.
Post reply on HN