Repeated pair positioning lookups could probably be optimized

[valadaptive]

When doing shaping+layout for the version of Ubuntu Light used in egui (Ubuntu-Light.ttf.zip), I noticed that we're spending a lot of time in pair_pos2_cached (20-30% of the shaping time!):

Here's the samply profile.

It seems that we re-parse the pair positioning table once per pair. Are we preparsing and caching these yet?

[behdad]

Thanks.

I'm curious in your debugger on Linux. What is that?

[valadaptive]

I'm curious in your debugger on Linux. What is that?

The Samply profiler. It displays profiling results in the Firefox profiler (actually completely browser-agnostic; it's just what Firefox uses). It's not a debugger (there's no stepping functionality) but it does show the source and assembly at least.

A few things to note:

• If you just drop a profile.json directly onto the profiler.firefox.com webpage, it'll appear to work but you'll lose all the debug info. To view someone else's profile, you'll need to use samply show, which acts as a symbol server.
• On Linux, you'll encounter two obtuse errors when first running it. One can be fixed with sudo sysctl kernel.perf_event_paranoid=1, the second ("mmap failed") with sudo sysctl kernel.perf_event_mlock_kb=2048. This is mentioned in samply's readme, but the "mmap failed" one still gets me sometimes.
• Right-clicking the boxes on the flame/stack graph, or the items in the call tree, gives you lots of useful options for filtering through the results (e.g. merging a function's self time into its callers, focusing on one specific call).

[valadaptive]

I should also mention how I run the profiler with the benchmarks. There might be a better way, but I look at the output from cargo bench, which provides the name of the binary:

[va_erie@Ampersand harfruzz]$ cargo bench
    Finished `bench` profile [optimized + debuginfo] target(s) in 0.07s
     Running benches/shaping.rs (target/release/deps/shaping-8b2dd32552295ccf)

I can then run:

samply record target/release/deps/shaping-8b2dd32552295ccf --bench [BENCHMARK_NAME]

--bench (and all the arguments after the binary name) are passed directly to the binary; I think all binary artifacts produced by cargo bench need that argument passed (even if you don't pass a specific benchmark name).

[dfrg]

This is the nature of OpenType layout running head first into fontations overhead.

The general OTL algorithm is

foreach lookup:
    foreach glyph:
        foreach subtable:

So we pay the cost of subtable parsing over and over. We can cache more with the trade off being additional memory use and more hand rolled parsing.

I’ll look into this.

[behdad]

Currently that font stands at 1.17xHB performance.

[behdad]

The Samply profiler. It displays profiling results in the Firefox profiler (actually completely browser-agnostic; it's just what Firefox uses). It's not a debugger (there's no stepping functionality) but it does show the source and assembly at least.

Just wanted to thank you. I set this up and find it very useful.

[behdad]

The Samply profiler.

Are you running a debug build? In my debugoptimized hb-harfrust build I don't see nice stacks for the Rust code. With debug build I do, but in my experience it doesn't represent reality. HB for example, becomes over 10x slower when not optimized, so the profile is not representative of reality.

I just ran debug benchmark of hb-harfrust and it's 50x slower for the test I ran.

Update: building with optimization level 2 at least brings it down to 1.3x slower and I still get a nice flamegraph. So it's on us to tune hb-harfrust build configuration better. This might be good enough. I'm still interested in your experience.

[valadaptive]

You can get full debug info in a release build by adding:

[profile.release]
debug = true

to your Cargo.toml. For a benchmark build (from the cargo bench command), it's:

[profile.bench]
debug = true

Cargo apparently also lets you create custom profiles, so you could create your own "release but with full debug info" profile.

[behdad]

You can get full debug info in a release build by adding:

[profile.release]
debug = true
to your Cargo.toml. For a benchmark build (from the cargo bench command), it's:

[profile.bench]
debug = true
Cargo apparently also lets you create custom profiles, so you could create your own "release but with full debug info" profile.

Yes, I have a custom debugoptimized. It was inheriting from release. Making it inherit from dev and passing optimize level to the rustc improved it:

harfbuzz/harfbuzz@ba4f92f