Advice on speeding up deserialization

[vshashi01]

I have a structure where a parent struct "Vertices" contains a collection for Vertex. This collection of vertex can be a large collection (typical professional use cases can be millions of vertices).

When serializing this, I see that this structure is my current largest bottleneck. I am still thinking what is the best optimization for this case?

#[derive(FromXml, ToXml, PartialEq, Clone, Debug)]
#[xml(ns(CORE_NS), rename = "vertices")]
pub struct Vertices {
    pub vertex: Vec<Vertex>,
}

/// A vertex in a triangle mesh
#[derive(FromXml, ToXml, PartialEq, Clone, Debug)]
#[xml(ns(CORE_NS), rename = "vertex")]
pub struct Vertex {
    #[xml(attribute)]
    pub x: f64,

    #[xml(attribute)]
    pub y: f64,

    #[xml(attribute)]
    pub z: f64,
}

So far I see 2 potential optimizations but I have not figured out how to approach them:

1. Reduce the overhead of dynamic allocation of the Vec.push() when assembling the Vec by overriding the FromXml impls of Vertices to provide a vec with preallocated memory.
2. Try to optimize the parsing for the Vertex struc such that it is deserialized in one go since it is in essence an attribute only Xml element (which should in theory make it easier). However, it is not super clear to me how I can override the FromXml implementation for Vertex such that I can take the whole element content as string.

I am open to suggestions on how else I can tackle this to improve my performance.

[djc]

Suggest starting with samply or flamegraph to see where the bottlenecks are. A pre-allocated Vec certainly seems like an obvious candidate, but better to know for sure.

Also still happy to take a look myself if you can provide a self-contained test case. So far I basically haven't done any performance optimization although I've tried to avoid obvious problems.

[vshashi01]

Thanks for the quick reply!

I did run samply on a bench test case I setup for this case. If you are interested, you can take a look at the bench in this repository: amrust_3mf

Both the vertex and triangle structures are similar in essence and they (as expected) pretty much dominate the whole deserialization step.

[vshashi01]

Note: I have branch called speedup that I am attempting to do this.

[djc]

djc-2021 main amrust_3mf $ samply record cargo bench --bench reader
error: failed to get `amrust_render` as a dependency of package `amrust_3mf v0.1.0 (/Users/djc/src/amrust_3mf)`

Caused by:
  failed to load source for dependency `amrust_render`

Caused by:
  Unable to update /Users/djc/src/amrust/amrust_render

Caused by:
  failed to read `/Users/djc/src/amrust/amrust_render/Cargo.toml`

[vshashi01]

Ah sorry, I am still working on replacing this internal dependency.

But meanwhile you can get around it by only enabling the necessary feature for the benchmark only with

cargo bench --features io

This should skip this dependency completely.

[djc]

That didn't work for me (I don't understand why exactly). And after I commented out the thumbnail modules, I ran into this error:

"/Users/djc/src/amrust_3mf/benches/3dmodel.model"
Benchmarking read_group/read instant_xml function: Warming up for 3.0000 s
thread 'main' panicked at benches/reader.rs:18:44:
called `Result::unwrap()` on an `Err` value: Parse(UnknownToken(TextPos { row: 1, col: 1 }))

[vshashi01]

Again thanks alot for looking into this.

The xml file "3dmodel.model" is a large file so its actually stored with Git LFS client. Is it possible Git LFS is not configured for you and you only have the stub of the file and not the actual xml file.

The file should look like below.

IF this is not the issue, I would say park it first.. i will try to make an even smaller example for this and reach out back.

[vshashi01]

I pushed a new branch with updated cargo features here : speedup_update

Now with this command it should ignore everything related to thumbnail correctly:

cargo bench --no-default-features --features core

[vshashi01]

For anyone interested about performance, I created a separate github repo that compares all the different XML serde in Rust supporting namespaces here, xml_bench using hotpath

The TLDR, the fastest of the lot currently seems to be serde-roxmltree which is approximately 30-40% faster than instant-xml in my workload as described above.

However, serde-roxmltree do have a peak memory usage of almost 2x more than the peak memory usage of instant-xml for similar use cases.

For now, pick the right one for your use case I guess.