[opentype/gpos] use plain struct instead of pointer

[benoitkugler]

During some benchmarks, I found tables.PairSet.FindGlyph was a really high source of heap allocations.
Using a plain struct (probably) allows the compiler/runtime to allocate it on the stack, resulting in a sizable reduction of heap allocations.

[whereswaldon]

@benoitkugler Do you have before/after benchmark info you could share?

[benoitkugler]

@benoitkugler Do you have before/after benchmark info you could share?

Here you are : the code simply runs Shaper.Shape, with a font using a GPOS table (Arimo).

Code

face := loadOpentypeFont(b, "/usr/share/fonts/truetype/croscore/Arimo-Regular.ttf")
textInput := []rune("Une jolie phrase en français !")
input := Input{
	Text:      textInput,
	RunStart:  0,
	RunEnd:    len(textInput),
	Direction: di.DirectionLTR,
	Size:      16 * 72,
	Face:      face,
	Script:    language.Latin,
	Language:  language.NewLanguage("fr"),
}
shaper := HarfbuzzShaper{}

b.ResetTimer()

for i := 0; i < b.N; i++ {
	_ = shaper.Shape(input)
}

Benchmark stats

       │   old.txt   │              new.txt               │
       │   sec/op    │   sec/op     vs base               │
GPOS-4   40.91µ ± 2%   37.47µ ± 5%  -8.41% (p=0.000 n=10)

       │   old.txt    │               new.txt                │
       │     B/op     │     B/op      vs base                │
GPOS-4   15.94Ki ± 0%   11.88Ki ± 0%  -25.48% (p=0.000 n=10)

       │  old.txt   │              new.txt               │
       │ allocs/op  │ allocs/op   vs base                │
GPOS-4   253.0 ± 0%   227.0 ± 0%  -10.28% (p=0.000 n=10)

Memory profile - Before:

Memory profile - After :

[andydotxyz]

Has the "After" trimmed the RunN contribution or did that go to 0?
I can't do the maths accurately on the fly but it looks like memory is just being moved to other places rather than reduced overall.

[benoitkugler]

Has the "After" trimmed the RunN contribution or did that go to 0? I can't do the maths accurately on the fly but it looks like memory is just being moved to other places rather than reduced overall.

My screenshot was incomplete, see the new one :

[whereswaldon]

I'm able to replicate the benchmark improvements:

$ benchstat before.out after.out
goos: linux
goarch: amd64
pkg: github.com/go-text/typesetting/shaping
cpu: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
       │ before.out  │             after.out              │
       │   sec/op    │   sec/op     vs base               │
GPOS-8   24.60µ ± 1%   22.76µ ± 1%  -7.48% (p=0.000 n=10)

       │  before.out   │              after.out               │
       │     B/op      │     B/op      vs base                │
GPOS-8   14.043Ki ± 0%   9.980Ki ± 0%  -28.93% (p=0.000 n=10)

       │ before.out │             after.out              │
       │ allocs/op  │ allocs/op   vs base                │
GPOS-8   219.0 ± 0%   193.0 ± 0%  -11.87% (p=0.000 n=10)

Even if this is just shifting an allocation to the caller's stack, the result is that memory is getting re-allocated fewer times during the shaping process, so it's still a net win.

[andydotxyz]

Thanks for the clarification :)