Live data from Hacker News

Node.js: Some quick optimization advice

medium.com

51–60 of 75 posts

Re: Node.js: Some quick optimization advice

#51
post #3

Earlier quoted context omitted.

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?

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

Re: Node.js: Some quick optimization advice

#52
post #50
post #41

Earlier quoted context omitted.

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.

In this one context, this one micro-optimization applies but for 99% of other cases, they don't (and shouldn't).

Note the 'benchmark' in OP is run 500 million times to see the performance difference. This is definitely not a common scenario.

Re: Node.js: Some quick optimization advice

#55
post #42
post #29

Earlier quoted context omitted.

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?

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 cliquish teenagers and rip them apart.

I don't mean to single you out. But this subthread consists of a developer at Amazon, an unknown, and a founder -- the very types of people I wanted to respect -- yet the content is little more than "Look at how stupid these people are." What kind of example are we setting here?

Be excited about X! Whether X is FOAM, Javascript, COBOL, C++, Python, Erlang, Scheme, NPM, ASDF, Vim, Stallman, or a song. Be happy. Be amused. Be anything but bitter.

In this instance, FOAM shows what's possible. Is it necessarily a good idea? Who cares! We've learned something new! Be excited!

How certain are you that an idea that strikes you as bad is actually bad? For every possible circumstance? What about with a slight tweak? In fact, "An idea that seems bad" is the short definition of "startup."

Most ideas that seem bad are, in fact, bad. But it's important to fully explore the problem space before dismissing them, else you'll dismiss Facebook.

This subthread is about a software technique, not a startup idea. But is it really such a different domain? Would the idea of Python have survived if it had been introduced in the era of Multics? It wasn't a compiled language, so it couldn't hope to survive back then. Yet its time was coming, whether or not it would have been dismissed at the time.

"Under what circumstances could this be a good idea?" That's the valuable question. And if you also have a good answer to "Why now?" then you may be onto something. In fact, you might be one of the first people to notice that an idea has flipped from bad to good. Seems like a pretty powerful position.

It seems like most influential work started as a hack. (TeX is a notable exception.) So if you want to do influential work, be delighted by hacks. It'll make them easier to explore, and you might end up in a position few others realize is valuable.

Re: Node.js: Some quick optimization advice

#56
post #34
post #19

Earlier quoted context omitted.

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.

Yes, and that's widely been regarded as a mistake.

Now that we have ES6 imports and wide CommonJS support I don't see any good reason to use hacky DI with Function#toString.

Re: Node.js: Some quick optimization advice

#57

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

Turbofan is an additional layer of optimization after Crankshaft.

Re: Node.js: Some quick optimization advice

#58
post #29
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...

Reminds me of Magento code for some reason.

Re: Node.js: Some quick optimization advice

#59
post #44

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…

> we should [...]

No, again, you're reforming "I would like..." into "we should". There's no should about it.

JavaScript is nowadays quite a nice language. ES2015 and the way forward gives us a language that could happily go for another 20 years with few issues.

WebAssembly doesn't solve the problem btw - most of the things people hate on JS about (that aren't just dumb "I don't like loose typing or understand prototypical inheritance" complaints anyhow) are to do with how it integrates with the key web feature: the DOM.

DOM is where everything goes to hell on the web and it's going to be just as much of a mess in C/Rust/Haskell/Clojure/brainfuck as it is in JavaScript.

Also your comment about Babel is just strange. The reason to use Babel is to support older parsers that only understand ES5 syntax. That's never going to go away. We'll be dealing with older parsers for 10 years after WebAssembly launches - so guess what? Now your toolchain got longer, more complex, and you still have to output JavaScript anyhow.

Yaaaaaay.

Or, you know, you could learn JavaScript properly and realize that it's a completely useful and great language that is just as good as whatever your pet favorite is when applied to the tasks at hand.

Re: Node.js: Some quick optimization advice

#60
post #52
post #50

Earlier quoted context omitted.

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.

In this one context, this one micro-optimization applies but for 99% of other cases, they don't (and shouldn't). Note the 'benchmark' in OP is run 500 million times to see the performance difference. This is definitely not a common scenario.

For me, it's more the principle of the thing. This just seems like an insane way for an interpreter to behave. Even more insane is the proposal of minifying server-side JS!
Post reply on HN