7 ms·
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 alre
by 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 agoI 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 agoSo 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 agoSo 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 agoThat makes sense. The js object syntax is much more complex than json.
- dosy 7y agoI ran it in JS perf and the myth is busted: https://jsperf.com/jpvol https://jsperf.com/jpvol
- s9w 7y agoYou're right, I didn't realize that.
- pier25 7y agoIs there a way to provide v8 with compiled code instead of unparsed JS?
- jackcodes 7y agoWhile 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 agoThanks. I was thinking more about desktop apps (Elecron, CEF, etc).
- ijpoijpoihpiuoh 7y agoI 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 agoHow many times?
- ijpoijpoihpiuoh 7y agoAccording to the fine article, twice in three days.
- colejohnson66 7y agoIsn’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 agoIE 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.