Hacker News Reader

Comment by ijpoijpoihpiuoh | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

That makes sense. The js object syntax is much more complex than json.

Is there a way to provide v8 with compiled code instead of unparsed JS?

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

Thanks. I was thinking more about desktop apps (Elecron, CEF, etc).

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.

How many times?

According to the fine article, twice in three days.

Isn’t that what Web Assembly (WASM) is attempting to do? It’s a bytecode, not machine code, so it’s processor agnostic too.

You're right, I didn't realize that.

Reply on news.ycombinator.com