You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are planning to remove serde_v8 completely. The reason is that in most cases using serde_v8 is a big footgun in terms of performance.
A stark example of perf footgun is URLPattern API that uses ops returning structures that are marked with #[serde]. This API produces a lot of garbage, just because it returns objects that have 8-9 keys. On each op invocation the key is serialized and copied from Rust to V8. Then in JavaScript, this object is immediately destructured and GCed. Instead we could return an array of values, which would alleviate a lot of pressure on GC.
This will need to happen over multiple PRs. The tentative plan of action is:
Remove serde_v8::AnyValue - this enum is used only for Deno KV APIs and can be easily replaced by using v8::Value directly.
Once AnyValue is gone, we can remove support for #[serde] arg in #[op2]. This is a big antipattern to pass structs as arguments - instead, the fields should be "unfurled" and passed as separate arguments to ops.
Remove support for other "magic" structs like JsBuffer, StringOrBuffer, BigInt, etc. Most of these could use specialized attributes or implement ToV8 and FromV8 traits directly.
At this point we should be able to remove #[serde] support in return value. Instead of returning structs we'd be returning v8::Array or v8::Value and it would be up to the caller to construct an object on JS side (if it's even needed). After checking deno repo we don't have that many occurrences and should be fairly straightfoward to update.
At this point, we should do the serde_v8 release saying that it's deprecated and unmaintained.
Remove serde_v8 crate altogether.
In the meantime we can remove serde_v8 benchmarks that will speed up CI in deno_core.
The text was updated successfully, but these errors were encountered:
As per #716 we are working
on replacing `serde_v8` with a new mechanism completely.
To that end, running benchmarks now is not that useful and only adds to
the overall CI time.
For Brioche, I use serde_v8 for quite a few of the important ops in the runtime. The data structures are fairly big and often deeply-nested, so I don't think translating these structures to a regular list of primitive arguments would be feasible
I could just use JSON.stringify() / serde_json::from_str() on either side, or I'm sure I could write some manual de/serialization for v8::Value types, but is there some general guidance or pattern to avoid either of these options?
Discussed extensively with @nathanwhit @mmastrac and @dsherret.
We are planning to remove
serde_v8
completely. The reason is that in most cases usingserde_v8
is a big footgun in terms of performance.A stark example of perf footgun is
URLPattern
API that uses ops returning structures that are marked with#[serde]
. This API produces a lot of garbage, just because it returns objects that have 8-9 keys. On each op invocation the key is serialized and copied from Rust to V8. Then in JavaScript, this object is immediately destructured and GCed. Instead we could return an array of values, which would alleviate a lot of pressure on GC.This will need to happen over multiple PRs. The tentative plan of action is:
serde_v8::AnyValue
- this enum is used only for Deno KV APIs and can be easily replaced by usingv8::Value
directly.AnyValue
is gone, we can remove support for#[serde] arg
in#[op2]
. This is a big antipattern to pass structs as arguments - instead, the fields should be "unfurled" and passed as separate arguments to ops.JsBuffer
,StringOrBuffer
,BigInt
, etc. Most of these could use specialized attributes or implementToV8
andFromV8
traits directly.#[serde]
support in return value. Instead of returning structs we'd be returningv8::Array
orv8::Value
and it would be up to the caller to construct an object on JS side (if it's even needed). After checkingdeno
repo we don't have that many occurrences and should be fairly straightfoward to update.serde_v8
release saying that it's deprecated and unmaintained.serde_v8
crate altogether.In the meantime we can remove
serde_v8
benchmarks that will speed up CI indeno_core
.The text was updated successfully, but these errors were encountered: