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

41–50 of 75 posts

Re: Node.js: Some quick optimization advice

#41

Post by nevi-me »

mixonic wrote: post #30

This is a good thing to raise awareness of, but the solution is poor advice. Asking developers to remember the "gotcha" of 600 characters is not really viable. Instead, if this is important to you, consider the addition of minification or comment stripping to your production deployment process. Minification will also make the variable names and syntax use shorter, saving you further precious characters. Learn the pro…

In the context of the article being on nodejs code; I don't know about other developers, but I don't minify my production nodejs code because it runs directly on the server. Whether I have `var nameThatIsStupidlyLong` or `var nTISL` doesn't make a difference because size of code isn't a concern.

What do other developers out there do?

Re: Node.js: Some quick optimization advice

#42

Post by phpnode »

clessg wrote: post #29
Dru89 wrote: post #28

Earlier quoted context omitted.

That might be one of the scariest things I've looked at all day.

It only gets better. https://github.com/foam-framework/foam/blob/master/apps/todo...

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?

Re: Node.js: Some quick optimization advice

#43

Post by nostrademons »

striking wrote: post #3
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?

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

No, V8 parses your Javascript source into an AST. From the AST, there are two paths it can take. The first step is the "full-codegen" compiler, which walks the AST directly and emits unoptimized native code:

http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-com...

If a function is hot, then it gets promoted to V8's optimizing compiler, which is currently Crankshaft but will soon be replaced by Turbofan. This compiles the AST first into a high-level IR, Hydrogen, which is an architecture-independent SSA-like form vaguely reminiscent of LLVM. Then that's lowered into an architecture-dependent IR, Lithium, where register allocation and instruction scheduling is performed.

http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-op...

If you read the bug for this that someone posted up-thread, the AST information is fully available when inlining in Hydrogen, but a patch to remove the character limit tanked one of their benchmarks. Also, they didn't preclude fixing it in Turbofan, only in Crankshaft, and that's largely because Crankshaft is on its way out.

(I've played a little with the internals of V8, but am not an official developer. Also, one of my friends is the Bay Area TL for V8.)

Re: Node.js: Some quick optimization advice

#44

Post by nikolay »

abritinthebay wrote: post #38
nikolay wrote: post #32

Earlier quoted context omitted.

"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.

Well, JavaScript became popular, because it was omnipresent and was simple (so that even Web Designers without a Computer Science degree could use it). Now, there are vast differences between browsers and the toolchain has grown huge.

We need to revisit the scripting in browsers. Instead of twisting arms to use "JavaScript", because of it "universality", we should focus on WebAssembly and the likes. Have a safe scripting VM in the browser, use any language that compiles to it - no need for Babel and the likes.

Re: Node.js: Some quick optimization advice

#45

Post by nostrademons »

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)

Pretty much every language that gets rapidly adopted has a lot of weird edge cases. You want to see weird edge cases, take a look at C++. Java got plenty of criticism too for things like the primitive/Object distinction, or that when they tried to fix it with autoboxing, it now meant that ordinary addition could throw an exception. And don't get me started on Perl or PHP.

The one possible exception may be Python, but this is because the PEP process requires that you very rigorously lay out interactions with existing language features, and Guido is pretty conservative at accepting them. This means Python evolves slower than many other languages, and the last attempt to fix many of the awkward rough corners (Python 3) led to a multi-year transition that adversely hurt Python's popularity for a long time.

As Bjarne Stroustrop said, "There are two kinds of languages: those that nobody likes, and those that nobody uses."

Re: Node.js: Some quick optimization advice

#46

Post by draperp »

nacs wrote: post #26
ep103 wrote: post #14

Earlier quoted context omitted.

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

> just minimize your code prior to production In frontend JS code sure, but minifying backend node.js code is certainly not "best practice".

Exactly. And if you did, you would have to look at source maps to decode your stack traces.

Re: Node.js: Some quick optimization advice

#47

Post by draperp »

diggan wrote: post #17
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.

Sure. And CPython isn't a language. It's the canonical Python implementation that is used 99% of the time.

When it comes to non-browser production code (e.g. servers), it's NodeJS or nothing.

Re: Node.js: Some quick optimization advice

#48

Post by alkonaut »

striking wrote: post #3
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?

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

> Things happen as they are parsed.

If comments aren't completely ignored by the parser, then there has to be some case where a comment inside a function has an observable effect?

Re: Node.js: Some quick optimization advice

#49

Post by mwfunk »

nikolay wrote: post #44
abritinthebay wrote: post #38

Earlier quoted context omitted.

> 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.

Well, JavaScript became popular, because it was omnipresent and was simple (so that even Web Designers without a Computer Science degree could use it). Now, there are vast differences between browsers and the toolchain has grown huge. We need to revisit the scripting in browsers. Instead of twisting arms to use "JavaScript", because of it "universality", we should focus on WebAssembly and the likes. Have a safe scrip…

People have been revisiting scripting in browsers for 15+ years. The hard part isn't getting everyone to revisit scripting in browsers. That's the easy part. If Google couldn't make it happen despite their efforts with Dart, I don't who else could. :( The push wouldn't come from the W3C either. I suspect that in 5-10 years, we will have a safe scripting VM in the browser, but it's still going to be JavaScript.

Re: Node.js: Some quick optimization advice

#50

Post by smt88 »

nevi-me wrote: post #41
mixonic wrote: post #30

This is a good thing to raise awareness of, but the solution is poor advice. Asking developers to remember the "gotcha" of 600 characters is not really viable. Instead, if this is important to you, consider the addition of minification or comment stripping to your production deployment process. Minification will also make the variable names and syntax use shorter, saving you further precious characters. Learn the pro…

In the context of the article being on nodejs code; I don't know about other developers, but I don't minify my production nodejs code because it runs directly on the server. Whether I have `var nameThatIsStupidlyLong` or `var nTISL` doesn't make a difference because size of code isn't a concern. What do other developers out there do?

Yeah, but the whole point of the article is that the names of your variables (and even your comments!!) do make a difference in performance.
Post reply on HN