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
I have benchmarked the roundtrip of a circuit via the path core -> model -> capnp -> model -> core. I was surprised about how slow it was; way slower than the JSON export. So I profiled to see where all the time goes. This is the export:
Most of the time is spent in OpType::port_kind, which takes so long since it copies a lot of stuff:
pubfnport_kind(&self,port:implInto<Port>) -> Option<EdgeKind>{let signature = self.dataflow_signature().unwrap_or_default();// <-- this deep copies he signaturelet port:Port = port.into();let dir = port.direction();let port_count = signature.port_count(dir);// Dataflow portsif port.index() < port_count {return signature.port_type(port).cloned().map(EdgeKind::Value);// <-- this deep copies the relevant type again}// ....}
Looking at the import, it's similar:
The first bump is mostly due to splitting strings into the extension and the name part. The remaining two bumps come from OpType::value_port_count, which spends most of its time copying data.
pubfnvalue_port_count(&self,dir: portgraph::Direction) -> usize{self.dataflow_signature()// <-- copy all of the signature just to count ports.map(|sig| sig.port_count(dir)).unwrap_or(0)}
The hugr-core data structures are designed in a way that you don't have to worry about ownership, which is not a bad thing. But there is a lot of deep copying, allocating and freeing going on, even just to look at something. There is a massive performance improvement to be had by being more careful here, not just for import or export, but for everything the compiler does that ever looks at types.
The most immediate and pragmatic approach that comes to my mind is to slap a lot of Arcs on as many types as possible, ideally in a way that minimally affects the API. (There are other approaches but they are too radical for now). What do you think?
The text was updated successfully, but these errors were encountered:
…1557)
A binary serialisation format for `hugr-model` based on capnproto.
- Export from `hugr-core` to `hugr-model` now deduplicates terms on the
fly.
- Removed types on ports and instead used the signature. This allows for
more deduplication and also provides a natural place for extension set
annotations which was missing before.
- Added the `NodeId` of the node that defines a parameter to the indexed
variant of a `LocalRef` so that deduplication does not accidentally
merge two local variables that refer to different parameters.
Serializing the same 2000 2-qubit gate + 1000 1-qubit gate circuit by
going from `core` via the `model` takes 5.5682 ms per roundtrip on Apple
M3. Meanwhile the JSON roundtrip baseline is 10.760 ms. A significant
portion of the time is spent on needless copies of signatures since
`export` and `import` have to interact with the `hugr-core` API (#1551),
so there is still a lot of potential to make this faster yet.
I have benchmarked the roundtrip of a circuit via the path

core -> model -> capnp -> model -> core
. I was surprised about how slow it was; way slower than the JSON export. So I profiled to see where all the time goes. This is the export:Most of the time is spent in
OpType::port_kind
, which takes so long since it copies a lot of stuff:Looking at the import, it's similar:

The first bump is mostly due to splitting strings into the extension and the name part. The remaining two bumps come from
OpType::value_port_count
, which spends most of its time copying data.The
hugr-core
data structures are designed in a way that you don't have to worry about ownership, which is not a bad thing. But there is a lot of deep copying, allocating and freeing going on, even just to look at something. There is a massive performance improvement to be had by being more careful here, not just for import or export, but for everything the compiler does that ever looks at types.The most immediate and pragmatic approach that comes to my mind is to slap a lot of
Arc
s on as many types as possible, ideally in a way that minimally affects the API. (There are other approaches but they are too radical for now). What do you think?The text was updated successfully, but these errors were encountered: