TextLayout.GenerateLayout generates a massive amount of garbage

[nolife99]

I am calling TextMeasurer.MeasureAdvance to cache character advances. Rider's DPA constantly notifies me of these specific allocations that generate a huge amount of garbage.

Here is the output from DPA:

Small Object Heap: code that allocates a lot of memory in SOH
Allocated object type: Flags
  Allocated size: 134.8 MB

at SimpleGlyphLoader.ReadCoordinates(BigEndianBinaryReader, int, Flags[], Flags, Flags)
at SimpleGlyphLoader.LoadSimpleGlyph(BigEndianBinaryReader, short, ref Bounds)
at GlyphLoader.Load(BigEndianBinaryReader)
at GlyphTable.Load(BigEndianBinaryReader, TableFormat, uint[], ref Bounds)
at GlyphTable.Load(FontReader)
at TableLoader.Load(FontReader)
at FontReader.TryGetTable()
at FontReader.GetTable()
at StreamFontMetrics.LoadTrueTypeFont(FontReader)
at StreamFontMetrics.LoadFont(FontReader)
at StreamFontMetrics.LoadFont(Stream)
at StreamFontMetrics.LoadFont(String, long)
at FileFontMetrics+<>c__DisplayClass3_0.<.ctor>b__0()
at FileFontMetrics.UpdatePositions(GlyphPositioningCollection)
at TextLayout.ProcessText(ReadOnlySpan, TextOptions)
at TextLayout.GenerateLayout(ReadOnlySpan, TextOptions)
at TextMeasurer.MeasureAdvance(ReadOnlySpan, TextOptions)
at TextMeasurer.MeasureAdvance(String, TextOptions)```

Small Object Heap: code that allocates a lot of memory in SOH
Allocated object type: ControlPoint[]
  Allocated size: 7.7 MB

at SimpleGlyphLoader.LoadSimpleGlyph(BigEndianBinaryReader, short, ref Bounds)
at GlyphLoader.Load(BigEndianBinaryReader)
at GlyphTable.Load(BigEndianBinaryReader, TableFormat, uint[], ref Bounds)
at GlyphTable.Load(FontReader)
at TableLoader.Load(FontReader)
at FontReader.TryGetTable()
at FontReader.GetTable()
at StreamFontMetrics.LoadTrueTypeFont(FontReader)
at StreamFontMetrics.LoadFont(FontReader)
at StreamFontMetrics.LoadFont(Stream)
at StreamFontMetrics.LoadFont(String, long)
at FileFontMetrics+<>c__DisplayClass3_0.<.ctor>b__0()
at FileFontMetrics.UpdatePositions(GlyphPositioningCollection)
at TextLayout.ProcessText(ReadOnlySpan, TextOptions)
at TextLayout.GenerateLayout(ReadOnlySpan, TextOptions)
at TextMeasurer.MeasureAdvance(ReadOnlySpan, TextOptions)
at TextMeasurer.MeasureAdvance(String, TextOptions)

Most of the memory survives gen1 collections, hurting performance

[JimBobSquarePants]

You need to load the font once and cache it.

[JimBobSquarePants]

Fonts contain a lot of information. I’m not sure what you’re expecting?

[nolife99]

I honestly feel like 130MB for measuring 100 glyphs is too much.
I don't have time to make a PR but using ArrayPool could be a possible solution, as the allocated types are arrays

[JimBobSquarePants]

To measure the glyphs you have to load the entire font. Font generally contain thousands of glyphs.

Array pooling would not help here. Pooling should be used for simple types (e.g byte) and you would very quickly exhaust any pool and you’d end up with the same allocation result. All you would have done would be to have massively complicated the code base.

I don't have time to make a PR

That’s a really poor attitude.

[nolife99]

I've discovered that the massive allocations come from boxing (using Enum.HasFlags). This theoretically should be an easy fix.

Fonts/src/SixLabors.Fonts/Tables/TrueType/Glyphs/SimpleGlyphLoader.cs

Lines 118 to 125 in 5767254

	if (flags[i].HasFlag(isByte))
	{
	byte b = reader.ReadByte();
	dx = (short)(flags[i].HasFlag(signOrSame) ? b : -b);
	}
	else
	{
	if (flags[i].HasFlag(signOrSame))

Changing these to a simple bitwise AND operation removes all nearly all allocations

[JimBobSquarePants]

What framework are you targeting? This boxing has gone from .NET 5+

https://learn.microsoft.com/en-us/visualstudio/profiling/performance-insights-enum-hasflag?view=vs-2022

[nolife99]

I'm currently using .NET 8. That's pretty strange, Enum.HasFlag is marked as a JIT intrinsic but still boxes the enum

[nolife99]

According to a few developers from C# discord, HasFlags sometimes still boxes (in tier 0 compilation) if JIT does not optimize it away. Seems like in this case it only passes tier 0 compilation.

[JimBobSquarePants]

Oh wow! OK. Should be an easy enough fix then. Thanks!