649646 - IndexedDB: Modify structured clone byte stream directly instead of using JS on DB thread

Status: NEW

(Core :: Storage: IndexedDB, task, P3)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

We currently deserialize, modify, and then reserialize structured clone data on the DB thread when adding to object stores that use inline keys and a key generator. In an effort to keep one runtime per thread we should just modify the data directly.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The basic use-case is something like this:

When serializing, we have an object like:

{
  foo: "bar",
  hello: { world: "fahrvergnugen" },
  deep: {},
  x: 2
}

At a later point, we want to modify the object such that it looks like:

{
  foo: "bar",
  hello: { world: "fahrvergnugen" },
  deep: { cow: { id: 4 } },
  x: 2
}


In other words, we want to set the property "deep.cow.id" to 4 (and in the process create any objects that are missing).


Another thing that might help is that the property being written is always a 64bit integer. And we know during the initial serialization where we'll want to write it. I.e. the name of the property that we want to set.

The only thing we don't know is the actual value.


One thing occurred to me though. We *could* actually implement this without any involvement of the structured clone code. What we could do is to store in the database the generated id, and store that separately from the serialized clone.

Then when reading data from the database we'd parse the serialized value and then insert the generated id in the newly created JS object. And do that every time when reading data from the database.

I'd likely not be as performant, but it'd get us off of using the runtime from the wrong thread.

Comment 2

[Shawn Wilsher :sdwilsh]

(In reply to comment #1)
> One thing occurred to me though. We *could* actually implement this without any
> involvement of the structured clone code. What we could do is to store in the
> database the generated id, and store that separately from the serialized clone.
We already do this AFAIK.

> Then when reading data from the database we'd parse the serialized value and
> then insert the generated id in the newly created JS object. And do that every
> time when reading data from the database.
This shouldn't be too hard to do.

Comment 3

[Andrew Overholt [:overholt]]

Given some recent discussions with the JS team, it seems like we want to do this some time soon.

Comment 4

[Ted Campbell [:tcampbell]]

To clarify, the following is the part that is interesting. It would allow using a single StructureSerialize when the spec currently involves two calls to this but avoid some of the existing complexity in trying to avoid the two copies.

(In reply to Jonas Sicking (:sicking) No longer reading bugmail consistently from comment #1) 
> One thing occurred to me though. We *could* actually implement this without
> any involvement of the structured clone code. What we could do is to store
> in the database the generated id, and store that separately from the
> serialized clone.
> 
> Then when reading data from the database we'd parse the serialized value and
> then insert the generated id in the newly created JS object. And do that
> every time when reading data from the database.

Comment 5

[Jan Varga [:janv]]

I wonder if we can move compression/decompression to content processes once we fix this.

Comment 6

[Jens Stutte [:jstutte]]

:janv, is this still something we would want to do?

Comment 7

[Jan Varga [:janv]]

Yes, this would definitely be a nice improvement.