20 ms·

The cost of parsing JSON

543 points by s9w 7y ago

ijpoijpoihpiuoh 7y ago
Title correction: it's faster to parse and initialize using JSON than to parse and compile the code required to initialize Objects directly. If the code is already compiled, it's much faster to initialize in code. At least that's my understanding of the linked article.
- jakelazaroff 7y ago
  I think your understanding is correct. The relevant quote: > 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.
  - vanderZwan 7y ago
    So is this insight limited to literals at page load, or are there situations where it might be faster to construct a JSON string and then parse it compared to directly creating the object? I'm thinking of compression libraries, or things like FlatBuffers.
  - harimau777 7y ago
    So that means that theoretically someone could write a Babel plugin that replaces objects with some sort of memoized JSON.parse in order to get the best of both worlds? Could that actually work in practice? Edit: I think you would also need to identify and only optimize objects that are handled immutably. However, my understanding is that you can do that in a compiler/transpiler fairly easily.
    - vanderZwan 7y ago
      > some sort of memoized JSON.parse in order to get the best of both worlds? Could that actually work in practice? Probably not, because the kind of object literals that can be converted to JSON.parse are the kind where you have different objects with the same shape, whereas reusing a memoized object would result in multiple references to the same object. EDIT: wait nvm, that's what you addressed with your edit.
- sbergot 7y ago
  That makes sense. The js object syntax is much more complex than json.
- dosy 7y ago
  I ran it in JS perf and the myth is busted: https://jsperf.com/jpvol https://jsperf.com/jpvol
- s9w 7y ago
  You're right, I didn't realize that.
- pier25 7y ago
  Is there a way to provide v8 with compiled code instead of unparsed JS?
  - jackcodes 7y ago
    While it isn’t exactly what you’re looking for, this is the closest thing I’m aware of for pure JS: https://prepack.io/ https://prepack.io/ and outside of that o guess you’re looking at WASM, although I know this isn’t exactly what you were asking for. But if your goal is to compile a little closer to v8 then you’d have to set v8 as your compilation target, making that only really worthwhile on the server (since you’d be missing out on all other browser runtimes). I could see such a thing being pretty useful for something CloudFlare workers where startup time is vital, and your execution environment is guaranteed to be v8. Unless of course they’ve managed to always keep them hot.
    - pier25 7y ago
      Thanks. I was thinking more about desktop apps (Elecron, CEF, etc).
  - ijpoijpoihpiuoh 7y ago
    I don't know about doing this directly with v8, but when used in the browser, the code will be cached after being compiled a certain number of times.
    - pier25 7y ago
      How many times?
      - ijpoijpoihpiuoh 7y ago
        According to the fine article, twice in three days.
  - colejohnson66 7y ago
    Isn’t that what Web Assembly (WASM) is attempting to do? It’s a bytecode, not machine code, so it’s processor agnostic too.
- keanebean86 7y ago
  IE has a similar issue with adding page elements. I was trying to add a bunch of tr/td elements to a page. My goal was to load a 5,000+ row excel file. I tried using document.createElement but it was painfully slow. I switch to string concatenation and element.innerHTML. It was about 30 times faster. This was only in IE 11 and edge. Chrome and Firefox took basically the same time for both. I added them all to a new, detatched tbody. After my appending loops I removed the existing tbody then appending the new tbody to the table.
TwoNineA 7y ago
Does this apply to other JS engines or only V8?
- jakelazaroff 7y ago
  > JSON.parse('…') is much faster to parse, compile, and execute compared to an equivalent JavaScript literal — not just in V8 (1.7× as fast), but in all major JavaScript engines.
- djsumdog 7y ago
  I was wondering that too. No mention of Firefox or Safari. There is more than one browser/render engine out there. Don't design for the monoculture.
  - jchw 7y ago
    JavascriptCore, Chakra and Spidermonkey appear in the benchmark...
    - djsumdog 7y ago
      ah I totally missed that! It's a link to their other benchmarks under the main graph; easy to miss: https://github.com/GoogleChromeLabs/json-parse-benchmark https://github.com/GoogleChromeLabs/json-parse-benchmark
      - kllrnohj 7y ago
        The graph in the article itself also has the other engines. You don't have to follow any link.
- jchw 7y ago
  Look at the chart specifically: > JSON.parse('…') is much faster to parse, compile, and execute compared to an equivalent JavaScript literal — not just in V8 (1.7× as fast), but in all major JavaScript engines.
- 7y ago
IggleSniggle 7y ago
Commenting the security issue from the end of explainer for visibility. I’m having flashbacks to the Java serialize vulnerabilities from a couple years ago. ECMAScript and JSON do not have the same set of escape characters: ``` Note: It’s crucially important to post-process user-controlled input to escape any special character sequences, depending on the context. In this particular case, we’re injecting into a <script> tag, so we must (also) escape </script, <script, and <!- -. ```
- Sephr 7y ago
  Why would you ever be escaping HTML in client-side JS? You should be using appropriate DOM APIs (which don't include innerHTML) to manipulate the document.
  - tracker1 7y ago
    If the JSON itself contains strings with markup included, and you're injecting directly into a script tag in the HTML document. Though, if you're dealing with a typed object server-side and/or loading into a .js file request, it's less of an issue, if you aren't supporting html markup in the object to begin with. In my own use case, both are true.
    - Sephr 7y ago
      Hence why I said "You should be using appropriate DOM APIs"... The appropriate DOM APIs don't take HTML strings in the first place. You shouldn't be passing HTML strings to JS.
  - IggleSniggle 7y ago
    I think you’ve missed the vulnerability. You can use appropriate DOM APIs all you want and be hit by a malicious escaper if you don’t serialize in the right way. At some point, your js is inserted into the document via a script tag. If you use the JSON parser to initialize your data more quickly, and your data has user input anywhere within it, then if you aren’t careful about encoding/decoding your string, the attacker’s can abruptly interrupt your own script simply by inserting `</script>//attacker script here`. It is comparable to an SQL injection attack, but instead it is HTML injection that is made possible if you use JSON.stringify without taking the differing character specification into account (the example in the write up shows one good way to do this). The attacker is escaping JSON.parse to escape HTML.
michaelmcmillan 7y ago
So I guess we should "transpile" static objects into strings that we call with JSON.parse? Not sure if I should end this comment with a /s or not.
- alxhill 7y ago
  That's...what the article proposes, so yes?
- deleted 7y ago
  [deleted]
- eloff 7y ago
  Since we compile JavaScript to an unreadable mess anyway... Why not?
- fenwick67 7y ago
  Sometimes you can have massive static objects. Like a list of emojis and their codepoints.[1] It could be useful in cases like that. You'd have to experiment, though. [1] https://raw.githubusercontent.com/joypixels/emoji-toolkit/master/emoji.json https://raw.githubusercontent.com/joypixels/emoji-toolkit/ma...
- alufers 7y ago
  The key part here is > As long as the JSON string is only evaluated once the JSON.parse approach is much faster. So doing this would only work on top-level declarations, because the javascript runtime will cache the parsed JSON structure for subsequent executions (eg. creating an object in a loop).
- nostrademons 7y ago
  WebPack, properly configured, will let you import plain old .json files through the normal es6 import mechanism. It doesn't use this technique though: the JSON file is treated as normal JS source (preprocessed to remove unnecessary quotes etc.) and wrapped with an export.
cryptica 7y ago
This is a terrible idea. 2x best-case performance is nothing. Especially not worth the extra hassle and complexity that it adds to the code. The sad thing about these kinds of articles is that there are people out there who will read this and actually start implementing it in their code.
- Trufa 7y ago
  What's the damage in knowing? I would say it falls under, good to know but be very careful. 2x performance is definitely not nothing if your corner case happens to benefit from this, if you prematurely optimize, that's on you.
- eloff 7y ago
  JSON.parse is complexity? Just separating your data from your code alone is worth it for the architectural benefits, this would be a net improvement to code quality. Performance matters, if you have a lot of data like this that can also be a big win.
  - Roboprog 7y ago
    Reading the data structure within the string is rather a nuisance, I think. It’s worth noting the caveat that there is a minimum size where this trick has a noticeable effect, though. I understand the original comment’s fear of abuse. Nice to know it’s there for huge data structures though. Huge: we’re talking about a browser, not a database server.
- Supermancho 7y ago
  > This is a terrible idea It's not just an idea, it's engineering with analysis. Smack on a pre-processor to wrap your cold start configurations (if they are large) and you'll get a performance boost, is the takeaway. > 2x best-case performance is nothing I'm not sure how you can say that with a straight face. Altering the bootup time of many systems by a factor is non-trivial.
gqcwwjtg 7y ago
This makes total sense, it really just means that the time it takes to compile JSON.parse on a string literal is offset by how much simpler and faster parsing a JSON object is than a js one.
- EGreg 7y ago
  Why isn’t the Javascript compiler storing an intermediate form after parsing the code? Then surely it would be faster to just execute the bytecode?
  - jackcodes 7y ago
    It is, I believe. The article seems to be saying you can get to that intermediate form more quickly by parsing the object from a string than you can parsing it as a POJO.
- SamBam 7y ago
  It seems that you could define a subset of JS Objects that are exactly those you could define with JSON (no functions, no recursion), and the browser could always read these more efficiently. With modern tooling, these could probably even be automatically be discovered at compile time, and all your `const a = {b: "c"}` objects could be changed into `const a = SimpleObject({b: "c"})`. Without that, you could probably use Typescript today to spit out JSON whenever the compiler saw that it was more efficient.
  - jacobr 7y ago
    There is no way of knowing someone won’t do a.foo = window.alert later though, unless it’s a frozen object
    - zeven7 7y ago
      That's also true of an object parsed with JSON.parse
      - 7y ago
sebringj 7y ago
If I had to do this in practice, I would still use plain javascript files in source but using JSON.stringify to files in some webpack process but still doesn't seem worth it.
deleted 7y ago
[deleted]
no_gravity 7y ago
Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript. Hmm.. shouldn't that hold for most programming languages then? Let's try it for PHP: time php -r 'for ($i=0;$i<10000000; $i++) $data = [1,2,3];' real 0m0,173s user 0m0,161s sys 0m0,012s time php -r 'for ($i=0;$i<10000000; $i++) $data = json_decode("[1,2,3]");' real 0m4,125s user 0m4,120s sys 0m0,005s So for 10 million repetitions, a small PHP structure is about 20x faster then parsing JSON. But to test the point of the article, one should use the sama data structure it uses (https://raw.githubusercontent.com/WebKit/webkit/ffdd2799d3237993354978b9d0cdd1d248fe3787/PerformanceTests/JetStream2/SeaMonster/inspector-json-payload.js https://raw.githubusercontent.com/WebKit/webkit/ffdd2799d323...) and parse it only once.
- eloff 7y ago
  This completely depends on the implementation of JSON in your language. That happens to be heavily optimized in JavaScript for obvious reasons.
- toast0 7y ago
  try json_decode(..., true) to get a similar data structure?
- alufers 7y ago
  I believe you are doing it wrong here, since the code is parsed only once and then executed in a loop in the first sample. If you parsed one array with 10000000 elements it should be faster.
  - no_gravity 7y ago
    Correct.
- elpocko 7y ago
  But you're not parsing the array 10000000 times in the first example. Use `eval`.
no_wizard 7y ago
Since a very common use of an object is simply as a Map, I wonder if this would apply to using Maps
- jedimastert 7y ago
  AFAIK (I'm not a js expert) there's not a huge difference behind the scenes.
epx 7y ago
This is the XOR AX,AX of the 21th century
- omginternets 7y ago
  What's XOR AX,AX of the 20th century?
  - fourthark 7y ago
    Shorter (in assembled bytes) and faster than MOV AX,0 https://stackoverflow.com/questions/33666617/what-is-the-best-way-to-set-a-register-to-zero-in-x86-assembly-xor-mov-or-and https://stackoverflow.com/questions/33666617/what-is-the-bes...
    - Doctor_Fegg 7y ago
      Goes back to the 8080, in fact.
  - root670 7y ago
    Fastest way to zero a register.
    - csirob 7y ago
      What is a 'register'? /s :)
  - nemo1618 7y ago
    xor'ing a value with itself produces 0, so XOR AX,AX is equivalent to "AX = 0". It's a common trick in assembly code because it's faster (and/or maybe more compact, can't remember) than the more obvious MOV AX,$0.
  - deleted 7y ago
    [deleted]
  - navaati 7y ago
    This is assembly. This instruction is doing an boolean "Exclusive Or" of a register named "AX" (think of a register like a hardware variable) with itself into itself. This always leave the register containing 0, because 0 XOR 0 = 0 and 1 XOR 1 = 0. And for some weird reason, doing that was faster than just doing MOV AX, 0 (which is literally "Move 0 into AX", so "AX = 0" in more familiar syntax). Edit: Oh man, my fellow HN'ers, as I did, all jumped on the occasion to show off :)
Tade0 7y ago
I think this fragment catches the spirit of this piece: A good rule of thumb is to apply this technique for objects of 10 kB or larger — but as always with performance advice, measure the actual impact before making any changes. Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who are kind enough to supply me both with such a file and a screencast. On a MacBook Pro a 2.6MB .har file takes about 140ms to parse and process.
- Klathmon 7y ago
  I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1] to incrementally parse the massive JSON blobs putting liberal `setTimeout`'s between each step to avoid hanging the main thread for more than about 200ms at a time. This meant that it would often take 5x longer to fully parse the JSON blob than just using `JSON.parse`, but it was a much nicer UX as the UI would never hang or freeze during that process (at least perceptively), and the user wasn't waiting on that parsing to happen to use the app, there was still more user-input I needed from them at that time. So even though it would often take 15+ seconds to parse now, the user was often spending 30+ seconds inputting more information, and now the UI would be fluid the whole time.
  - nostrebored 7y ago
    Why not just use promises? side note: legit question, I don't do web/app dev
    - Kuinox 7y ago
      Because JS is single threaded. If a task is too big you need to split it or the UI can't be updated until the task is done.
19ylram49 7y ago
I mean, I get it, but I think performance is overrated in this particular case; unless it’s a significant and/or very noticeable difference, stick to object literals, please. I’d probably fire someone if I started to see `JSON.parse(…)` everywhere in a codebase just for “performance reasons” … remember, code readability and maintainability are just as important (if not more).
- edf13 7y ago
  No there’re not
  - chuckgreenman 7y ago
    Most development time is going to be spent on reading code that's already written, so yes, they do matter. With the speeds mentioned it's not going to be appreciable until you hit a massive scale, which, let's face it, most of us aren't working with.
    - edf13 7y ago
      Most dev time for people refactoring code - yes... but not for new projects. And as you say some people do write at scale. > code readability and maintainability are just as important (if not more). This is wrong, that’s all I was saying. Code right and it is readable anyway
    - tracker1 7y ago
      Well, we're talking about injected variables... const injectedValue = JSON.parse("$SERVER_JSON_VALUE.replace("\"","\\\"")"); // vs const injectedValue = $SERVER_JSON_VALUE; generally for a single value in the codebase is emphatically NOT a huge issue... and if it saves 80-120ms or so on the load, that's a significant impact. Not to mention the lower memory overhead while doing so.
- Klathmon 7y ago
  They say in the linked article that this should only be used for objects about 10kb and larger. I'd argue that if you have 10kb or larger object literals in your codebase, you are already missing the mark on readability and maintainability in some ways.
janpot 7y ago
makes total sense for transferring state for a server side rendered app.
olliej 7y ago
Having worked on parsing + code generation for object literals, the performance is not just a matter of JSON being simpler (IMO the difference in parsing cost is negligible). The problem with object literals is the cost of code generation, in cpu time and memory usage, and then subsequent execution. The difference is so monumental that JSC will try to parse any JS first as a JSONP-style object literal, because the cost of attempting the object literal parse is so small. For small literals that are hit multiple times, the literal will be faster in the long term - JSON.parse() results in opaque shape for the result which hinders lowering, etc, and the implementation is somewhat generalized to the case a large object graphs so many of the space improvements that happen for object literals don't happen.
yoz-y 7y ago
It would be nice to introduce data literals to JS so we would get this + syntax verification.
drtz 7y ago
Couldn't this same performance boost be achieved by adding an optional "strict mode"-like flag for object literals to v8? Adding JSON.parse(…) everywhere you need an object literal seems exceptionally kludgy, even for JS.
- xsmasher 7y ago
  something like let map = {{ x:7, y:13 }}; where the double-brackets promise you're only going to do JSONish stuff in there
ChrisArchitect 7y ago
this came up at a conference I was at last week (FITC WEBU/Toronto) in a talk by Houssein Djirdeh from Google entitled "What's New in Speed at Google?" Someone asked if it was recommended everyone start refactoring their code to have this change and he replied it would depend on size of project/code etc..as the performance benefit might not be there for huge things, but in some smaller cases it could definitely be a plus.
xg15 7y ago
I'm somewhat surprised that parsing an JS object literal is slower than: tokenizing a string literal, resolving all escapes/unicode encodings/etc, resolving the JSON object, resolving the JSON.parse() function, invoking the function, context-switching to native and then actually parsing the JSON. (Though you can probably do some optimizations, such as treating "JSON.parse" as a keyword if you can be sure nothing tampered with it) However, if that's the case, it sounds like a good candidate for an optimisation for V8: why not speculatively try to parse object literals as JSON and only fall back to JS if this causes an error? Also, didn't their note about Chrome's bytecode cache kind of defeat their point? Yes, JSON would be faster on first load, but it should be slower on subsequent loads as the parsed object can be pulled from the bytecode cache while the JSON literal has to be parsed again on each load.
- tynorf 7y ago
  > However, if that's the case, it sounds like a good candidate for an optimisation for V8: why not speculatively try to parse object literals as JSON and only fall back to JS if this causes an error? I wouldn't be surprised if the vast majority of object literals in the wild are not valid JSON for one reason or another: - Object keys and string literals not quoted with `"`. - Non literal/non primitive values. - Trailing commas.
nicoburns 7y ago
I wish there was an option for off the main thread ("async") parsing of JSON. It's easy to cause UI lag by parsing (or serializing) large objects, and this seems very unnecessary.
- adossi 7y ago
  I see this sentiment echoed a few times in this discussion thread. I use JSON daily, parsing and serializing everywhere, and yet I've never been in a scenario where I needed to parse a very large JSON object on the client side. The biggest JSON objects I work with are in the neighborhood of ~80 MB, but the client's browser never sees those behemoths. At most I return a few KB to the client's browser via an API response where it is then parsed and consumed. Is this notably a problem where the back-end is written in JavaScript?
  - nicoburns 7y ago
    It's a frontend problem, not a backend problem. The case I've seen it most is trying to store large objects in localstorage for consumption offline. You obviously end up with more data in this case. Mobile browsers are the biggest problem, they (and desktop ie sometimes) can struggle with objects of even a few hundred kb.
vardump 7y ago
Battery life. People seem to love to dismiss small improvements, even if they're practically effortless. Remember, faster performance equals lower battery consumption. Bad slow javascript causes browsers to waste energy. Small things add up.
bryanrasmussen 7y ago
I actually think the previous title of this article which was something about JSON.parse being faster than object instantiation or something like was clearer because in English the cost of something implies that it is a negative, whereas here the performance cost is a benefit relative to another solution with a higher cost. maybe I'm being picky though.
- leovailati 7y ago
  I agree. I was expecting something about protocol buffers or a binary based representation of JSON.
- tpurves 7y ago
  I was expecting something about the extent to which JSON processing in the world contributes to global warming or some such
  - gnarbarian 7y ago
    Parsing 1GB of flat JSON data is equal to 1.61 metric cow farts.
    - tabtab 7y ago
      Don't tell people that. Those who believe climate change is a hoax will then do it more out of spite against the alleged hoaxers. Think I'm joking?: https://www.scientificamerican.com/article/not-so-conservative-saving-energy/ https://www.scientificamerican.com/article/not-so-conservati...
      - core-questions 7y ago
        Literally parsing carbon-shittons of JSON right now out of spite. It's worth the spot instance cost! Especially since the power usage + carbon created is on the other side of the world from me! Mwahahah! relaxes in pure pristine air-shed
      - deleted 7y ago
CountHackulus 7y ago
So I guess AOT compilation is coming? That seems to be the next logical step. Cache compiled versions of your code in a format that can be loaded directly into memory. Java does it if set up to do so and it definitely gets better startup performance. Plus you get a pre-warmed compile cache.
- pas 7y ago
  Isn't this what WASM was supposed to be?
drinchev 7y ago
Well I guess this means that if you have a 1k+ lines of static JSON, it would be better if you consider converting it to a string and use JSON.parse instead. I'm not sure I can find a use case of such a big object declaration. Usually what you do is to get it from somewhere ( file, db - with nodejs, xhr ) where it's been parsed with JSON.parse anyway.
- Roboprog 7y ago
  I guess somebody needed to do that, but I am totally with you that this sounds like a follow up request or read for metadata to me.
jokoon 7y ago
isn't opening binary data faster than parsing text?
StreamBright 7y ago
>> Facebook loads ~6MB of compressed JS across ~292 requests What a time to be alive.
- maga 7y ago
  It usually took me ~20 min to download an mp3 around that size through dial up back in the day. Indeed what a time.
higherkinded 7y ago
Curious! Instantiation by means of the language is actually slower than parsing stuff and instantiating the objects that way. Didn't ever think of that possibility before. Anyway, I understand that JavaScript is much more complicated to parse than bare JSON, but still, that just feels odd. Good read!
mumblemumble 7y ago
Deliberately provocative conversation piece: If you're concerned enough about performance, or message passing costs are enough of an overall performance bottleneck, that parsing your messages even 1.7x as fast is worth changing the way you code, you probably shouldn't be using JSON as your message format in the first place.
- EB66 7y ago
  We're talking about JavaScript in the browser though... what other message format is more readily and performantly processed in-browser using JavaScript than JSON?
  - manfredo 7y ago
    Infrastructure for protobufs is pretty effective. It is parsed in browser, but several implementations show better performance than JSON decoding. A unified set of libraries (or rather, code generators) to encode and decode in various languages is a plus, too. Both my current and last company used protobufs to encode API request data, as well as for things like config loading.
  - est31 7y ago
    Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines, you could make the case for usage of binary formats like protobuf. IMO this trend of piling on technology after technology to handle bloat instead of designing websites to be lean is wrong but it's certainly the direction we are walking into. Websites will become even more opaque and complex. Definitely not looking forward to it.
    - AgentOrange1234 7y ago
      I don’t think this is a one-or-the-other situation. “Bloat” is a problem on, say, news sites with horrible ads and it’d be great if they kept it lean. Obviously they don’t need webassembly and binary formats. But... there are also incredibly powerful tools (google maps and docs, quake in the browser, streaming services, etc) that push the boundaries, which these kinds of tech will enhance, or make possible in the first place.
anderslaub 7y ago
Dangerous advice if object values can contain string terminates.. var obj = { "Name": "Joe`s sloppy" }; will work well as plain object while obj = JSON.parse('{ "Name": "Joe's sloppy" }'); Will kill your site.. hard to control especially with several different unicode characters all being interpreted as plings
anderslaub 7y ago
Dangerous advice if object values potentially can contain string terminators.. var obj = { "Name": "Joe`s sloppy place" }; will work well as plain object while obj = JSON.parse('{ "Name": "Joe's sloppy place" }'); Will kill your site.. hard to control especially with several different unicode characters all being interpreted as plings by json parse..
helpmepropose 7y ago
I was hoping this blog post would be about the Chrome team speeding up JSON parsing. On a website I made[1] with a ~1MB JSON ajax payload, Chrome takes about 18 seconds to parse the JSON, while Safari parses it pretty much instantaneously. [1] https://helpmepropose.live https://helpmepropose.live EDIT: Does anyone know if there's something I could do differently to speed this up in Chrome?
- underwater 7y ago
  Why not use binary data? A typed array should work (unsure of the exact APIs, though).
  - helpmepropose 7y ago
    Hey underwater, I just wanted to follow up and say thanks. Without doing any other optimization, it seems that switching the ajax request from JSON to a big TypedArray changed Chrome's parsing time from 18 seconds to instantaneous: https://helpmepropose.live https://helpmepropose.live Thanks again!
  - helpmepropose 7y ago
    That's a good idea, thanks! I'd previously thought typed arrays had to be initialized with data that's already in memory, but it looks like I was wrong there. This page is giving some hints that it can be done: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#Properties https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...
mirimir 7y ago
I like JSON. It's easy to generate in Calc, and `curl -X POST` is fast enough.
doque 7y ago
An interesting library I've found that tackles this issue is yieldable-json: https://developer.ibm.com/node/2017/11/13/yieldable-json-asynchronous-json-module-node-js/ https://developer.ibm.com/node/2017/11/13/yieldable-json-asy...

543 points by s9w 7y ago

Title correction: it's faster to parse and initialize using JSON than to parse and compile the code required to initialize Objects directly. If the code is already compiled, it's much faster to initialize in code. At least that's my understanding of the linked article.

jakelazaroff 7y ago
I think your understanding is correct. The relevant quote: > 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.
- vanderZwan 7y ago
  So is this insight limited to literals at page load, or are there situations where it might be faster to construct a JSON string and then parse it compared to directly creating the object? I'm thinking of compression libraries, or things like FlatBuffers.
- harimau777 7y ago
  So that means that theoretically someone could write a Babel plugin that replaces objects with some sort of memoized JSON.parse in order to get the best of both worlds? Could that actually work in practice? Edit: I think you would also need to identify and only optimize objects that are handled immutably. However, my understanding is that you can do that in a compiler/transpiler fairly easily.
  - vanderZwan 7y ago
    > some sort of memoized JSON.parse in order to get the best of both worlds? Could that actually work in practice? Probably not, because the kind of object literals that can be converted to JSON.parse are the kind where you have different objects with the same shape, whereas reusing a memoized object would result in multiple references to the same object. EDIT: wait nvm, that's what you addressed with your edit.
sbergot 7y ago
That makes sense. The js object syntax is much more complex than json.
dosy 7y ago
I ran it in JS perf and the myth is busted: https://jsperf.com/jpvol https://jsperf.com/jpvol
s9w 7y ago
You're right, I didn't realize that.
pier25 7y ago
Is there a way to provide v8 with compiled code instead of unparsed JS?
- jackcodes 7y ago
  While it isn’t exactly what you’re looking for, this is the closest thing I’m aware of for pure JS: https://prepack.io/ https://prepack.io/ and outside of that o guess you’re looking at WASM, although I know this isn’t exactly what you were asking for. But if your goal is to compile a little closer to v8 then you’d have to set v8 as your compilation target, making that only really worthwhile on the server (since you’d be missing out on all other browser runtimes). I could see such a thing being pretty useful for something CloudFlare workers where startup time is vital, and your execution environment is guaranteed to be v8. Unless of course they’ve managed to always keep them hot.
  - pier25 7y ago
    Thanks. I was thinking more about desktop apps (Elecron, CEF, etc).
- ijpoijpoihpiuoh 7y ago
  I don't know about doing this directly with v8, but when used in the browser, the code will be cached after being compiled a certain number of times.
  - pier25 7y ago
    How many times?
    - ijpoijpoihpiuoh 7y ago
      According to the fine article, twice in three days.
- colejohnson66 7y ago
  Isn’t that what Web Assembly (WASM) is attempting to do? It’s a bytecode, not machine code, so it’s processor agnostic too.
keanebean86 7y ago
IE has a similar issue with adding page elements. I was trying to add a bunch of tr/td elements to a page. My goal was to load a 5,000+ row excel file. I tried using document.createElement but it was painfully slow. I switch to string concatenation and element.innerHTML. It was about 30 times faster. This was only in IE 11 and edge. Chrome and Firefox took basically the same time for both. I added them all to a new, detatched tbody. After my appending loops I removed the existing tbody then appending the new tbody to the table.

TwoNineA 7y ago

Does this apply to other JS engines or only V8?

jakelazaroff 7y ago
> JSON.parse('…') is much faster to parse, compile, and execute compared to an equivalent JavaScript literal — not just in V8 (1.7× as fast), but in all major JavaScript engines.
djsumdog 7y ago
I was wondering that too. No mention of Firefox or Safari. There is more than one browser/render engine out there. Don't design for the monoculture.
- jchw 7y ago
  JavascriptCore, Chakra and Spidermonkey appear in the benchmark...
  - djsumdog 7y ago
    ah I totally missed that! It's a link to their other benchmarks under the main graph; easy to miss: https://github.com/GoogleChromeLabs/json-parse-benchmark https://github.com/GoogleChromeLabs/json-parse-benchmark
    - kllrnohj 7y ago
      The graph in the article itself also has the other engines. You don't have to follow any link.
jchw 7y ago
Look at the chart specifically: > JSON.parse('…') is much faster to parse, compile, and execute compared to an equivalent JavaScript literal — not just in V8 (1.7× as fast), but in all major JavaScript engines.
7y ago

IggleSniggle 7y ago

Commenting the security issue from the end of explainer for visibility. I’m having flashbacks to the Java serialize vulnerabilities from a couple years ago. ECMAScript and JSON do not have the same set of escape characters: ``` Note: It’s crucially important to post-process user-controlled input to escape any special character sequences, depending on the context. In this particular case, we’re injecting into a <script> tag, so we must (also) escape </script, <script, and <!- -. ```

Sephr 7y ago
Why would you ever be escaping HTML in client-side JS? You should be using appropriate DOM APIs (which don't include innerHTML) to manipulate the document.
- tracker1 7y ago
  If the JSON itself contains strings with markup included, and you're injecting directly into a script tag in the HTML document. Though, if you're dealing with a typed object server-side and/or loading into a .js file request, it's less of an issue, if you aren't supporting html markup in the object to begin with. In my own use case, both are true.
  - Sephr 7y ago
    Hence why I said "You should be using appropriate DOM APIs"... The appropriate DOM APIs don't take HTML strings in the first place. You shouldn't be passing HTML strings to JS.
- IggleSniggle 7y ago
  I think you’ve missed the vulnerability. You can use appropriate DOM APIs all you want and be hit by a malicious escaper if you don’t serialize in the right way. At some point, your js is inserted into the document via a script tag. If you use the JSON parser to initialize your data more quickly, and your data has user input anywhere within it, then if you aren’t careful about encoding/decoding your string, the attacker’s can abruptly interrupt your own script simply by inserting `</script>//attacker script here`. It is comparable to an SQL injection attack, but instead it is HTML injection that is made possible if you use JSON.stringify without taking the differing character specification into account (the example in the write up shows one good way to do this). The attacker is escaping JSON.parse to escape HTML.

michaelmcmillan 7y ago

So I guess we should "transpile" static objects into strings that we call with JSON.parse? Not sure if I should end this comment with a /s or not.

alxhill 7y ago
That's...what the article proposes, so yes?
deleted 7y ago
[deleted]
eloff 7y ago
Since we compile JavaScript to an unreadable mess anyway... Why not?
fenwick67 7y ago
Sometimes you can have massive static objects. Like a list of emojis and their codepoints.[1] It could be useful in cases like that. You'd have to experiment, though. [1] https://raw.githubusercontent.com/joypixels/emoji-toolkit/master/emoji.json https://raw.githubusercontent.com/joypixels/emoji-toolkit/ma...
alufers 7y ago
The key part here is > As long as the JSON string is only evaluated once the JSON.parse approach is much faster. So doing this would only work on top-level declarations, because the javascript runtime will cache the parsed JSON structure for subsequent executions (eg. creating an object in a loop).
nostrademons 7y ago
WebPack, properly configured, will let you import plain old .json files through the normal es6 import mechanism. It doesn't use this technique though: the JSON file is treated as normal JS source (preprocessed to remove unnecessary quotes etc.) and wrapped with an export.

cryptica 7y ago

This is a terrible idea. 2x best-case performance is nothing. Especially not worth the extra hassle and complexity that it adds to the code. The sad thing about these kinds of articles is that there are people out there who will read this and actually start implementing it in their code.

Trufa 7y ago
What's the damage in knowing? I would say it falls under, good to know but be very careful. 2x performance is definitely not nothing if your corner case happens to benefit from this, if you prematurely optimize, that's on you.
eloff 7y ago
JSON.parse is complexity? Just separating your data from your code alone is worth it for the architectural benefits, this would be a net improvement to code quality. Performance matters, if you have a lot of data like this that can also be a big win.
- Roboprog 7y ago
  Reading the data structure within the string is rather a nuisance, I think. It’s worth noting the caveat that there is a minimum size where this trick has a noticeable effect, though. I understand the original comment’s fear of abuse. Nice to know it’s there for huge data structures though. Huge: we’re talking about a browser, not a database server.
Supermancho 7y ago
> This is a terrible idea It's not just an idea, it's engineering with analysis. Smack on a pre-processor to wrap your cold start configurations (if they are large) and you'll get a performance boost, is the takeaway. > 2x best-case performance is nothing I'm not sure how you can say that with a straight face. Altering the bootup time of many systems by a factor is non-trivial.

gqcwwjtg 7y ago

This makes total sense, it really just means that the time it takes to compile JSON.parse on a string literal is offset by how much simpler and faster parsing a JSON object is than a js one.

EGreg 7y ago
Why isn’t the Javascript compiler storing an intermediate form after parsing the code? Then surely it would be faster to just execute the bytecode?
- jackcodes 7y ago
  It is, I believe. The article seems to be saying you can get to that intermediate form more quickly by parsing the object from a string than you can parsing it as a POJO.
SamBam 7y ago
It seems that you could define a subset of JS Objects that are exactly those you could define with JSON (no functions, no recursion), and the browser could always read these more efficiently. With modern tooling, these could probably even be automatically be discovered at compile time, and all your `const a = {b: "c"}` objects could be changed into `const a = SimpleObject({b: "c"})`. Without that, you could probably use Typescript today to spit out JSON whenever the compiler saw that it was more efficient.
- jacobr 7y ago
  There is no way of knowing someone won’t do a.foo = window.alert later though, unless it’s a frozen object
  - zeven7 7y ago
    That's also true of an object parsed with JSON.parse
    - 7y ago

sebringj 7y ago

If I had to do this in practice, I would still use plain javascript files in source but using JSON.stringify to files in some webpack process but still doesn't seem worth it.

deleted 7y ago

[deleted]

no_gravity 7y ago

Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript. Hmm.. shouldn't that hold for most programming languages then? Let's try it for PHP: time php -r 'for ($i=0;$i<10000000; $i++) $data = [1,2,3];' real 0m0,173s user 0m0,161s sys 0m0,012s time php -r 'for ($i=0;$i<10000000; $i++) $data = json_decode("[1,2,3]");' real 0m4,125s user 0m4,120s sys 0m0,005s So for 10 million repetitions, a small PHP structure is about 20x faster then parsing JSON. But to test the point of the article, one should use the sama data structure it uses (https://raw.githubusercontent.com/WebKit/webkit/ffdd2799d3237993354978b9d0cdd1d248fe3787/PerformanceTests/JetStream2/SeaMonster/inspector-json-payload.js https://raw.githubusercontent.com/WebKit/webkit/ffdd2799d323...) and parse it only once.

eloff 7y ago
This completely depends on the implementation of JSON in your language. That happens to be heavily optimized in JavaScript for obvious reasons.
toast0 7y ago
try json_decode(..., true) to get a similar data structure?
alufers 7y ago
I believe you are doing it wrong here, since the code is parsed only once and then executed in a loop in the first sample. If you parsed one array with 10000000 elements it should be faster.
- no_gravity 7y ago
  Correct.
elpocko 7y ago
But you're not parsing the array 10000000 times in the first example. Use `eval`.

no_wizard 7y ago

Since a very common use of an object is simply as a Map, I wonder if this would apply to using Maps

jedimastert 7y ago
AFAIK (I'm not a js expert) there's not a huge difference behind the scenes.

epx 7y ago

This is the XOR AX,AX of the 21th century

omginternets 7y ago
What's XOR AX,AX of the 20th century?
- fourthark 7y ago
  Shorter (in assembled bytes) and faster than MOV AX,0 https://stackoverflow.com/questions/33666617/what-is-the-best-way-to-set-a-register-to-zero-in-x86-assembly-xor-mov-or-and https://stackoverflow.com/questions/33666617/what-is-the-bes...
  - Doctor_Fegg 7y ago
    Goes back to the 8080, in fact.
- root670 7y ago
  Fastest way to zero a register.
  - csirob 7y ago
    What is a 'register'? /s :)
- nemo1618 7y ago
  xor'ing a value with itself produces 0, so XOR AX,AX is equivalent to "AX = 0". It's a common trick in assembly code because it's faster (and/or maybe more compact, can't remember) than the more obvious MOV AX,$0.
- deleted 7y ago
  [deleted]
- navaati 7y ago
  This is assembly. This instruction is doing an boolean "Exclusive Or" of a register named "AX" (think of a register like a hardware variable) with itself into itself. This always leave the register containing 0, because 0 XOR 0 = 0 and 1 XOR 1 = 0. And for some weird reason, doing that was faster than just doing MOV AX, 0 (which is literally "Move 0 into AX", so "AX = 0" in more familiar syntax). Edit: Oh man, my fellow HN'ers, as I did, all jumped on the occasion to show off :)

Tade0 7y ago

I think this fragment catches the spirit of this piece: A good rule of thumb is to apply this technique for objects of 10 kB or larger — but as always with performance advice, measure the actual impact before making any changes. Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who are kind enough to supply me both with such a file and a screencast. On a MacBook Pro a 2.6MB .har file takes about 140ms to parse and process.

Klathmon 7y ago
I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1] to incrementally parse the massive JSON blobs putting liberal `setTimeout`'s between each step to avoid hanging the main thread for more than about 200ms at a time. This meant that it would often take 5x longer to fully parse the JSON blob than just using `JSON.parse`, but it was a much nicer UX as the UI would never hang or freeze during that process (at least perceptively), and the user wasn't waiting on that parsing to happen to use the app, there was still more user-input I needed from them at that time. So even though it would often take 15+ seconds to parse now, the user was often spending 30+ seconds inputting more information, and now the UI would be fluid the whole time.
- nostrebored 7y ago
  Why not just use promises? side note: legit question, I don't do web/app dev
  - Kuinox 7y ago
    Because JS is single threaded. If a task is too big you need to split it or the UI can't be updated until the task is done.

19ylram49 7y ago

I mean, I get it, but I think performance is overrated in this particular case; unless it’s a significant and/or very noticeable difference, stick to object literals, please. I’d probably fire someone if I started to see `JSON.parse(…)` everywhere in a codebase just for “performance reasons” … remember, code readability and maintainability are just as important (if not more).

edf13 7y ago
No there’re not
- chuckgreenman 7y ago
  Most development time is going to be spent on reading code that's already written, so yes, they do matter. With the speeds mentioned it's not going to be appreciable until you hit a massive scale, which, let's face it, most of us aren't working with.
  - edf13 7y ago
    Most dev time for people refactoring code - yes... but not for new projects. And as you say some people do write at scale. > code readability and maintainability are just as important (if not more). This is wrong, that’s all I was saying. Code right and it is readable anyway
  - tracker1 7y ago
    Well, we're talking about injected variables... const injectedValue = JSON.parse("$SERVER_JSON_VALUE.replace("\"","\\\"")"); // vs const injectedValue = $SERVER_JSON_VALUE; generally for a single value in the codebase is emphatically NOT a huge issue... and if it saves 80-120ms or so on the load, that's a significant impact. Not to mention the lower memory overhead while doing so.
Klathmon 7y ago
They say in the linked article that this should only be used for objects about 10kb and larger. I'd argue that if you have 10kb or larger object literals in your codebase, you are already missing the mark on readability and maintainability in some ways.

janpot 7y ago

makes total sense for transferring state for a server side rendered app.

olliej 7y ago

Having worked on parsing + code generation for object literals, the performance is not just a matter of JSON being simpler (IMO the difference in parsing cost is negligible). The problem with object literals is the cost of code generation, in cpu time and memory usage, and then subsequent execution. The difference is so monumental that JSC will try to parse any JS first as a JSONP-style object literal, because the cost of attempting the object literal parse is so small. For small literals that are hit multiple times, the literal will be faster in the long term - JSON.parse() results in opaque shape for the result which hinders lowering, etc, and the implementation is somewhat generalized to the case a large object graphs so many of the space improvements that happen for object literals don't happen.

yoz-y 7y ago

It would be nice to introduce data literals to JS so we would get this + syntax verification.

drtz 7y ago

Couldn't this same performance boost be achieved by adding an optional "strict mode"-like flag for object literals to v8? Adding JSON.parse(…) everywhere you need an object literal seems exceptionally kludgy, even for JS.

xsmasher 7y ago
something like let map = {{ x:7, y:13 }}; where the double-brackets promise you're only going to do JSONish stuff in there

ChrisArchitect 7y ago

this came up at a conference I was at last week (FITC WEBU/Toronto) in a talk by Houssein Djirdeh from Google entitled "What's New in Speed at Google?" Someone asked if it was recommended everyone start refactoring their code to have this change and he replied it would depend on size of project/code etc..as the performance benefit might not be there for huge things, but in some smaller cases it could definitely be a plus.

xg15 7y ago

I'm somewhat surprised that parsing an JS object literal is slower than: tokenizing a string literal, resolving all escapes/unicode encodings/etc, resolving the JSON object, resolving the JSON.parse() function, invoking the function, context-switching to native and then actually parsing the JSON. (Though you can probably do some optimizations, such as treating "JSON.parse" as a keyword if you can be sure nothing tampered with it) However, if that's the case, it sounds like a good candidate for an optimisation for V8: why not speculatively try to parse object literals as JSON and only fall back to JS if this causes an error? Also, didn't their note about Chrome's bytecode cache kind of defeat their point? Yes, JSON would be faster on first load, but it should be slower on subsequent loads as the parsed object can be pulled from the bytecode cache while the JSON literal has to be parsed again on each load.

tynorf 7y ago
> However, if that's the case, it sounds like a good candidate for an optimisation for V8: why not speculatively try to parse object literals as JSON and only fall back to JS if this causes an error? I wouldn't be surprised if the vast majority of object literals in the wild are not valid JSON for one reason or another: - Object keys and string literals not quoted with `"`. - Non literal/non primitive values. - Trailing commas.

nicoburns 7y ago

I wish there was an option for off the main thread ("async") parsing of JSON. It's easy to cause UI lag by parsing (or serializing) large objects, and this seems very unnecessary.

adossi 7y ago
I see this sentiment echoed a few times in this discussion thread. I use JSON daily, parsing and serializing everywhere, and yet I've never been in a scenario where I needed to parse a very large JSON object on the client side. The biggest JSON objects I work with are in the neighborhood of ~80 MB, but the client's browser never sees those behemoths. At most I return a few KB to the client's browser via an API response where it is then parsed and consumed. Is this notably a problem where the back-end is written in JavaScript?
- nicoburns 7y ago
  It's a frontend problem, not a backend problem. The case I've seen it most is trying to store large objects in localstorage for consumption offline. You obviously end up with more data in this case. Mobile browsers are the biggest problem, they (and desktop ie sometimes) can struggle with objects of even a few hundred kb.

vardump 7y ago

Battery life. People seem to love to dismiss small improvements, even if they're practically effortless. Remember, faster performance equals lower battery consumption. Bad slow javascript causes browsers to waste energy. Small things add up.

bryanrasmussen 7y ago

I actually think the previous title of this article which was something about JSON.parse being faster than object instantiation or something like was clearer because in English the cost of something implies that it is a negative, whereas here the performance cost is a benefit relative to another solution with a higher cost. maybe I'm being picky though.

leovailati 7y ago
I agree. I was expecting something about protocol buffers or a binary based representation of JSON.
tpurves 7y ago
I was expecting something about the extent to which JSON processing in the world contributes to global warming or some such
- gnarbarian 7y ago
  Parsing 1GB of flat JSON data is equal to 1.61 metric cow farts.
  - tabtab 7y ago
    Don't tell people that. Those who believe climate change is a hoax will then do it more out of spite against the alleged hoaxers. Think I'm joking?: https://www.scientificamerican.com/article/not-so-conservative-saving-energy/ https://www.scientificamerican.com/article/not-so-conservati...
    - core-questions 7y ago
      Literally parsing carbon-shittons of JSON right now out of spite. It's worth the spot instance cost! Especially since the power usage + carbon created is on the other side of the world from me! Mwahahah! relaxes in pure pristine air-shed
    - deleted 7y ago

CountHackulus 7y ago

So I guess AOT compilation is coming? That seems to be the next logical step. Cache compiled versions of your code in a format that can be loaded directly into memory. Java does it if set up to do so and it definitely gets better startup performance. Plus you get a pre-warmed compile cache.

pas 7y ago
Isn't this what WASM was supposed to be?

drinchev 7y ago

Well I guess this means that if you have a 1k+ lines of static JSON, it would be better if you consider converting it to a string and use JSON.parse instead. I'm not sure I can find a use case of such a big object declaration. Usually what you do is to get it from somewhere ( file, db - with nodejs, xhr ) where it's been parsed with JSON.parse anyway.

Roboprog 7y ago
I guess somebody needed to do that, but I am totally with you that this sounds like a follow up request or read for metadata to me.

jokoon 7y ago

isn't opening binary data faster than parsing text?

StreamBright 7y ago

>> Facebook loads ~6MB of compressed JS across ~292 requests What a time to be alive.

maga 7y ago
It usually took me ~20 min to download an mp3 around that size through dial up back in the day. Indeed what a time.

higherkinded 7y ago

Curious! Instantiation by means of the language is actually slower than parsing stuff and instantiating the objects that way. Didn't ever think of that possibility before. Anyway, I understand that JavaScript is much more complicated to parse than bare JSON, but still, that just feels odd. Good read!

mumblemumble 7y ago

Deliberately provocative conversation piece: If you're concerned enough about performance, or message passing costs are enough of an overall performance bottleneck, that parsing your messages even 1.7x as fast is worth changing the way you code, you probably shouldn't be using JSON as your message format in the first place.

EB66 7y ago
We're talking about JavaScript in the browser though... what other message format is more readily and performantly processed in-browser using JavaScript than JSON?
- manfredo 7y ago
  Infrastructure for protobufs is pretty effective. It is parsed in browser, but several implementations show better performance than JSON decoding. A unified set of libraries (or rather, code generators) to encode and decode in various languages is a plus, too. Both my current and last company used protobufs to encode API request data, as well as for things like config loading.
- est31 7y ago
  Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines, you could make the case for usage of binary formats like protobuf. IMO this trend of piling on technology after technology to handle bloat instead of designing websites to be lean is wrong but it's certainly the direction we are walking into. Websites will become even more opaque and complex. Definitely not looking forward to it.
  - AgentOrange1234 7y ago
    I don’t think this is a one-or-the-other situation. “Bloat” is a problem on, say, news sites with horrible ads and it’d be great if they kept it lean. Obviously they don’t need webassembly and binary formats. But... there are also incredibly powerful tools (google maps and docs, quake in the browser, streaming services, etc) that push the boundaries, which these kinds of tech will enhance, or make possible in the first place.

anderslaub 7y ago

Dangerous advice if object values can contain string terminates.. var obj = { "Name": "Joe`s sloppy" }; will work well as plain object while obj = JSON.parse('{ "Name": "Joe's sloppy" }'); Will kill your site.. hard to control especially with several different unicode characters all being interpreted as plings

anderslaub 7y ago

Dangerous advice if object values potentially can contain string terminators.. var obj = { "Name": "Joe`s sloppy place" }; will work well as plain object while obj = JSON.parse('{ "Name": "Joe's sloppy place" }'); Will kill your site.. hard to control especially with several different unicode characters all being interpreted as plings by json parse..

helpmepropose 7y ago

I was hoping this blog post would be about the Chrome team speeding up JSON parsing. On a website I made[1] with a ~1MB JSON ajax payload, Chrome takes about 18 seconds to parse the JSON, while Safari parses it pretty much instantaneously. [1] https://helpmepropose.live https://helpmepropose.live EDIT: Does anyone know if there's something I could do differently to speed this up in Chrome?

underwater 7y ago
Why not use binary data? A typed array should work (unsure of the exact APIs, though).
- helpmepropose 7y ago
  Hey underwater, I just wanted to follow up and say thanks. Without doing any other optimization, it seems that switching the ajax request from JSON to a big TypedArray changed Chrome's parsing time from 18 seconds to instantaneous: https://helpmepropose.live https://helpmepropose.live Thanks again!
- helpmepropose 7y ago
  That's a good idea, thanks! I'd previously thought typed arrays had to be initialized with data that's already in memory, but it looks like I was wrong there. This page is giving some hints that it can be done: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#Properties https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...

mirimir 7y ago

I like JSON. It's easy to generate in Calc, and `curl -X POST` is fast enough.

doque 7y ago

An interesting library I've found that tackles this issue is yieldable-json: https://developer.ibm.com/node/2017/11/13/yieldable-json-asynchronous-json-module-node-js/ https://developer.ibm.com/node/2017/11/13/yieldable-json-asy...