Node.js: Some quick optimization advice • Hacker News Board

Re: Node.js: Some quick optimization advice

#71

Post by spullara » Tue, Oct 13, 2015, 4:30 PM UTC

alkonaut wrote: post #68

ycitm wrote: post #51

Earlier quoted context omitted.

Yup, see @pauljz's comment above - https://news.ycombinator.com/item?id=10375297

I still don't understand that. Function.prototype.toString() wouldn't break because the parser stripped the comments, it would just output the source without comments? Does any code anywhere depend on the comments being preserved?

People literally toString functions and parse them to implement features. Those features depend on there being comment text in the function that they parse. Pretty much a terrible hack but it is true that you can't remove the comments without breaking current code.

Re: Node.js: Some quick optimization advice

#72

Post by WorldWideWayne » Tue, Oct 13, 2015, 5:26 PM UTC

STRML wrote: post #20

xlm1717 wrote: post #12

Earlier quoted context omitted.

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.

If the function is nested within another function, then the comments to document the inner function are going to exist inside the outer function. And having nested functions is a very common scenario in JS.

Re: Node.js: Some quick optimization advice

#73

Post by WorldWideWayne » Tue, Oct 13, 2015, 5:29 PM UTC

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.

Thank you. So, due to the extra work that is required I'm going to say YES - this is one point in favor of not preferring inline docs.

I think all the dissenters missed that part (about it being "one point" in favor/not in favor). I thought programmers were supposed to be good with subtle details, but it seems like the majority of them lose that ability when talking about religious topics.

Re: Node.js: Some quick optimization advice

#74

Post by alkonaut » Tue, Oct 13, 2015, 6:10 PM UTC

spullara wrote: post #71

alkonaut wrote: post #68

Earlier quoted context omitted.

I still don't understand that. Function.prototype.toString() wouldn't break because the parser stripped the comments, it would just output the source without comments? Does any code anywhere depend on the comments being preserved?

People literally toString functions and parse them to implement features. Those features depend on there being comment text in the function that they parse. Pretty much a terrible hack but it is true that you can't remove the comments without breaking current code.

Wow. That's just something that should be an obvious fix in a future ES. Not only does it hurt the optimizer, it also seems to imply that the content of comments sometimes has semantic meaning in the code, such as people having invented directives etc.

Surely this must be undocumented features of the language spec?

Re: Node.js: Some quick optimization advice

#75

Post by phpnode » Thu, Oct 22, 2015, 8:54 PM UTC

strayptr wrote: post #55

phpnode wrote: post #42

Earlier quoted context omitted.

it's incredible that that project has 11,000 commits, a huge amount of effort has gone into it but the code is really unpleasant to read. I feel like I must be missing something about FOAM - who is using it and why?

Let's stop trashing on people's work. The success of an endeavor is proportional to the number of shitty hacks that have come before it. Sometimes this it true in a literal sense -- sometimes a project consists of shitty hacks. But the astute reader will notice that a hack is only known to be shitty because someone did it , and had the courage to make their example public. Do we reward their courage? No. We act like…

For what it's worth I was asking a genuine question, most experimental projects don't get 11k commits so I assume that people are actively using it - my question is, given the plethora of alternatives available, what is it about FOAM that leads people to use it?

I shouldn't have said that the code was unpleasant, which is obviously subjective, but I should have said "the code style is quite unusual for JS", which it is. It was certainly not my intention to "trash their work".