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

11–20 of 75 posts

Re: Node.js: Some quick optimization advice

#11

Post by madflame991 »

WorldWideWayne wrote: post #6

So, 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…

> So, is this is a point in favor of not commenting your Javascript code or using inline docs?

You can of course strip comments when making builds. In fact you can even write functions of more than 600 chars and get away with it as long as you use a minifier. If you have a minified function of more than 600 chars then that's a bulky function which should instead be split in smaller ones.

Re: Node.js: Some quick optimization advice

#12

Post by xlm1717 »

WorldWideWayne wrote: post #6

So, 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…

I wonder what performance gains/losses you would experience if you had the comment outside the function block, before the function declaration.

Re: Node.js: Some quick optimization advice

#13

Post by xlm1717 »

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.

Re: Node.js: Some quick optimization advice

#14

Post by ep103 »

WorldWideWayne wrote: post #6

So, 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…

no, just minimize your code prior to production, and that'll rip out the comments. That's been best practice for years.

Re: Node.js: Some quick optimization advice

#15

Post by untog »

WorldWideWayne wrote: post #6

So, 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…

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.

Re: Node.js: Some quick optimization advice

#16

Post by dap »

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 pointed out, you could use a minimizer.

If your program is not CPU-bound, or if it doesn't have a function that's called millions of times in a tight loop, or if that doesn't make up the majority of time spent on CPU, or if that function does more than execute a couple of instructions, then the performance difference will likely be enormously less.

Re: Node.js: Some quick optimization advice

#17

Post by diggan »

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)

Well, to be fair. Node is not a language and this hack is not a "feature" or whatever of the language, rather it's a hack to get V8 to inline functions. JavaScript as an language is all right, but as always, making this language work and perform in multiple environments is tricky sometimes.

Re: Node.js: Some quick optimization advice

#18

Post by chrisseaton »

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 browsed to a different page.

Re: Node.js: Some quick optimization advice

#19

Post by STRML »

untog wrote: post #15
WorldWideWayne wrote: post #6

So, 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…

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.

Re: Node.js: Some quick optimization advice

#20

Post by STRML »

xlm1717 wrote: post #12
WorldWideWayne wrote: post #6

So, 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…

I wonder what performance gains/losses you would experience if you had the comment outside the function block, before the function declaration.

Exactly, if the comment were outside the function, there would be no issue.
Post reply on HN