6 ms·
As a JS dilettante, I found this incredibly surprising. const data = { foo: 42, bar: 1337 }; // >>> can be represented in JSON-stringified form, and then
by elbasti 7y ago
As a JS dilettante, I found this incredibly surprising.
const data = { foo: 42, bar: 1337 }; //
>>> can be represented in JSON-stringified form, and then JSON-parsed at runtime:
const data = JSON.parse('{"foo":42,"bar":1337}'); //
>>> As long as the JSON string is only evaluated once, the JSON.parse approach is much faster compared to the JavaScript object literal, especially for cold loads.
- jasim 7y agoThis is great! Is the optimization applicable in Firefox?
- badfrog 7y agoI'd be interested to see some data on the real impact of "much faster". I can't imagine object parsing would be a large cost in the big picture.
- czechdeveloper 7y agoIt make sense if you think about it, but I would really not figure it out myself, that is true.
- mordechai9000 7y agoI read the comments before the article, and it took me a minute to figure out why: Of course, JSON is much simpler to parse than JS. For anything large enough to matter, I think you'd want to deliver it as an application/json blob, anyway. Or use protobuf.
- blondin 7y agoindeed! and i was going to say the same thing. it makes perfect sense if you are a programmer with a basic understanding of how languages work. but like someone else said, i would not have thought about it first thing when writing code.
- yyyk 7y agoPerhaps the reason many (like myself) did not immediately expect the speedup is that they started on or are still using another non-scripting programming languages. There, the language parsing penalty is paid during the compile step, and as far as a user is concerned the object approach is obviously faster than parsing from JSON. This does leave me wandering - is the result here applicable to other scripting languages too? The argument in the article would seem to apply in the general case, but perhaps other languages have some particularities that change the result.
- uhryks 7y ago> can be applied to improve start-up performance for web apps that ship __large__ JSON-like configuration object literals They don't say how large but clearly it's not going to be better for a 2 keys object like in the example.
- untog 7y agoI worry this is going to become new accepted wisdom without being tested fully (it's probably already a Webpack plugin). My questions: - What about other browsers? - how big does it have to be to have a meaningful effect? I've seen an example out there with someone demonstrating amazing gains... on their 163KB of initial state. That's not typical. Or at least I really hope it isn't.
- ForHackernews 7y agoWhat do you mean "other" browsers? Legacy non-Chrome browsers are deprecated, anyway.
- gavinpc 7y agoUmm, Firefox? Or am I misunderstanding?
- leadingthenet 7y agoIt was a joke.
- c0vfefe 7y agoneeds a /s
- baron816 7y agoI hate these microperformance hacks. There’s no way you’re going to have a bottleneck here and you’re making the quality of your code dramatically worse.
- moltar 7y agoI don’t think this is meant to be hand written though. But a bundle/compiler can do this optimization for you.
- jammygit 7y agoThis did not occur to me but is obvious now that you have said it. Interesting! I wonder how many such tweaks it would take it to be worthwhile for companies to add it as a build step
- microwavecamera 7y agoI understand what you and OP are getting at and I'm saying it's wrong but it misses the broader point that others posters were positing. The exact same point I came to make but found myself in good company. Why?!? And it's not specific to JS or a direct criticism of JS, this issue it becoming endemic. It's happening everywhere now. We shouldn't have to depend on language specific hacks to make things "work" in that language. JS has gotten so out of hand now we have/need new metalanguages like TypeScript, CoffeeScript, Bable, (insert buzzwordy JS lang here) that transpiles into JS because it's become so unwieldy. All this just to be able to make a simple web app. The fact that V8 can parse JSON faster than processing a native JS literal is a compiler problem. Why is it suddenly my problem? It's one thing if it's a bug that we have to temporarily work around (these things happen) but now it's becoming the norm. How are people new to the industry supposed to learn something like JS if the only way to be proficient at it is through an endless, ever changing array of hacks? Especially when it's something as counterintuitive as parsing a string is somehow faster than the actual equivalent code. The "move fast and break things" mentality that has permeated tech as of late has done just that, got us nowhere fast and broke everything along the way.
- efrafa 7y agoInterresting discussion over this https://twitter.com/mathias/status/1143551692732030979?s=21 https://twitter.com/mathias/status/1143551692732030979?s=21
- pmarreck 7y agoHow the heck is this faster? What's going on underneath? This violates the hell out of Principle of Least Surprise lol
- taylorlapeyre 7y agoSince JSON’s syntax is much simpler and smaller, it’s faster to parse a very large object as JSON and return the newly built JavaScript object rather than parse the object tree in JavaScript, which has a much more complex syntax parser. Obviously there’s diminishing returns for smaller and smaller objects.
- gmueckl 7y agoThe Json version only requires the full, complex JS parser to find the end of the string parameter. The string itself is then passed to a specialized Json parser that is faster because the language is a lot simpler and it has to check less possibilities at each point. Apparently this is faster than running the whole string through the full JS parser that has has to deal with all kinds of portential shenanigans in that block like references to variables instead of literals etc.
- vbezhenar 7y agoBut that only applies to the parsing step. With JSON.parse you will parse it every time the code executes, so if that code is in function, JavaScript probably will be better, because compiler can't just optimize out JSON.parse (because someone might redefine window.JSON object or redefine its parse property).
- hedora 7y agoThat’s why you should put all your json literals at the topmost scope in the file. After all, global variables are the best variables. (Per the article’s advice, unless I’m missing something)
- hinkley 7y agoIs the perf discrepancy any different with 'use strict;'?