Add SVG parsing and rendering runtime benchmark

[Kobzol]

Runtime benchmark that tests parsing and rendering of a big-ass ~30 MiB SVG file from Wikipedia.

So far I have been mostly including these test files directly into the binary (and sometimes inflating/repeating them). I wonder if there is any disadvantage to this, as opposed to loading them at runtime (at the beginning of the program). I like that the embedding makes the runtime benchmarks more self-contained and I don't have to think about in which working directory they are being executed.

The stddev of instructions in rendering is pretty low, which is sweet. For parsing it's much higher on the other hand, but still relatively low percentually wise (0.01%).

Finished svg/svg-parse-1 (1/2)
    [Instructions]: min:   5,457,509,897    mean:    5,458,332,985    stddev:     712,250
          [Cycles]: min:   1,506,487,031    mean:    1,523,466,816    stddev:  13,656,702
  [Wall time [µs]]: min:         355,597    mean:          363,953    stddev:       8,486
   [Branch misses]: min:       3,009,549    mean:        3,033,586    stddev:      23,441
    [Cache misses]: min:       2,316,998    mean:        2,375,970    stddev:      38,273

Finished svg/svg-render-1 (2/2)
    [Instructions]: min:   1,382,696,182    mean:    1,382,696,213    stddev:          18
          [Cycles]: min:     565,619,974    mean:      575,163,087    stddev:  11,329,955
  [Wall time [µs]]: min:         136,351    mean:          138,703    stddev:       1,496
   [Branch misses]: min:       3,213,874    mean:        3,224,041    stddev:      11,126
    [Cache misses]: min:         934,657    mean:          957,595    stddev:      33,268

[nnethercote]

In #1618 you were worried about me adding an 800KiB benchmark, and this is 30MiB. Does it need to be that big?

[Kobzol]

Yeah I also remembered my comment :) I guess that the difference for me was that the additional files for the compile benchmark were useless to us, while this file serves an actual purpose. But you are right that 30 MiB is a lot.

Repeating/inflating SVG isn't that simple as e.g. for CSS, but I'll try to think of something to reduce the file size, while keeping the benchmark reasonably long. I guess that we can always just do N iterations of parsing.

[Mark-Simulacrum]

One approach if we don't mind network access is to put the files outside the repo (e.g., S3) - which at least keeps the repo itself small, even though in practice I guess they're still needed to run things.

[Kobzol]

I would like to avoid introducing such remote dependency into the benchmark, and thus making it less self-contained. It's true that we also have to download all crate dependencies from the internet, but that is cached in CARGO_HOME basically forever. Here, if we would download the file in main (or in a build script), it would download ~30 MiB off the internet everytime the benchmark is built/executed (since the builds are isolated by default and recreated every time), and if the download wouldn't succeed, it would basically fail the benchmark.

After gzipping the file, it is ~4.5 MiB. Would such size be acceptable? It's not that easy to simply repeat SVG files, as it is e.g. with CSS. If it's still too big, I'll try to find a SVG that compresses better or somehow generate it dynamically by repeating some of its inner contents.

[nnethercote]

I can live with the 4.5MB gzipped file.

[Kobzol]

Ok. I added documentation about adding runtime benchmark input files and how to (de)compress them. I force-pushed the compressed SVG file, so that the larger original file is not in git history. I also compressed the 11 MiB text file that was already present in the repo (this won't help with it being included in git history, but at least it will be smaller on disk and in the binary).

[Kobzol]

@nnethercote Let me know if you have any further comments :)

[nnethercote]

Sorry, I overlooked the re-review.