On Sat, Jul 24, 2021 at 2:02 AM Jace Mogill <j...@mogill.com> wrote: > Complementary data and task parallel JSON lexing implementations already > exists (https://github.com/simdjson/simdjson, > https://github.com/mogill/parallel-xml2json) but there's no way to store > the results in a way V8 can use, and thus an extra copy in/out step is > needed. >
Note that V8's JSON parsing generates mutable, introspectable JavaScript objects, with all their prototypal inheritance, monkey patching possibility, iteration semantics, garbage collection compatibility, interaction with V8's inline caches for property access, etc.. The actual JSON _parsing_ of V8's JSON parser is quite competitive, it's the rest of this stuff that takes the additional time. > I see several "bookend" options which may be combined to varying degrees: > - A lowest common denominator data storage sequence is defined by V8 > - Applications gain the ability to introspect about V8's object storage > sequences at runtime > - Applications can tell V8 how data is stored in memory and V8 can adapt > to an existing storage sequence > Since you are already using the C++ API, you can already do this by creating Object templates and registering interceptors on them which defer to your existing external storage. This will make the JSON parsing fast, at the cost of property access and memory management being slow, but there's no way for these to _not_ be slow without integrating with the rest of the system, at which point you're back to paying all the costs of V8's existing JSON parsing. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAGRskv-nJtp-x3gtwKNgyUrv8U5C6%2BTwDU_H7rUtqKuafBEQRQ%40mail.gmail.com.
