JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.
For large JSON-compatible objects, JSON.parse is faster than JS object literals.
True for all browser JavaScript engines!
Speed-ups from 1.2× to 2×
My #ChromiumDevSummit lightning talk explains why:https://www.youtube.com/watch?v=ff4fgQxPaO0 …
-
Does this JSON.parse optimization offer any benefit once code caching kicks in? It seems to reduce the large parse cost in favour of slightly greater execution cost. But when code caching, JS parsing is almost free, whereas execution cost still matters.
Did you see the benchmark referenced in the talk? It includes warm load tests: https://github.com/GoogleChromeLabs/json-parse-benchmark/blob/7ffba303e10910faa93cab2ba9bd643c8686a995/bench.sh#L37-L40 … cc @leszekswirski @tverwaes for code caching insights specifically
-
-
The trade-off space here is pretty large - with code caching specifically, you save on parsing but you pay for deserialisation of the strings and object boilerplates. For multiple initialisations it still makes sense, but for a single one it's a bit of a toss up.
-
Indeed, if you evaluate a literal many times in the same run of a program, that's faster than JSON.parse. The advice mainly applies to larger config objects. (Even there it depends whether you have large constant strings or complex objects.) "It depends" isn't as catchy :-)
- Još 3 druga odgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.