Performance improvements

[UkoeHB]

Areas for perf improvement:

• Buffer::set_text can be optimized in a similar fashion to Big optimizations for Buffer::set_rich_text #303.
• Use SmallVec instead of Vec where it makes sense. This should somewhat reduce the cost to make new buffers.
  • Optimize for single-line single-span single-word text #311
• There are two allocations at the top of set_rich_text that can be moved to ShapeBuffer.
• Internally, ShapeLine is essentially a Vec<Vec<Vec<ShapeGlyph>>>. This can be flattened into two vecs: a vec of indices + metadata and a vec of ShapeGlyphs. Or even one vec with the metadata in-line.
  • I attempted this but got stuck on the need to sometimes reverse words and glyphs in ShapeSpan. It may be less efficient to reverse elements of a flattened vec than the current implementation.
• Internally, BufferLine caches a Vec<LayoutLine>, which is essentially Vec<Vec<LayoutGlyph>>. This could also be flattened.
  • The challenge here is needing/using [LayoutGlyph] in the layout iterator. We would no longer have access to a raw slice of glyphs.
• Buffer caches a ShapeBuffer but it would be better to have this in FontSystem or elsewhere for global reuse.
  • Move ShapeBuffer to FontSystem #307
• FontFallbackIter::monospace_fallbacks can be injected or reused from FontSystem
  • Cache the monospace fallbacks buffer in FontSystem #309
• shape_fallback() returns a Vec that isn’t reused, and takes a Vec of glyphs. These can be moved to ShapeBuffer.
• ShapeLine::adjust_levels produces a Vec that can be cached.
• ShapeLine::build makes a new unicode_bidi::BidiInfo every time, which contains multiple allocations.
  • Sadly, unicode-bidi is not designed to let you reuse allocations. wizterm-bidi looks like it might be more performant, but the API is more restricted and I got stuck trying to test it out (it also doesn't support no-std).
• ShapeLine::reorder allocates twice internally.
• BidiParagraphs makes a new unicode_bidi::BidiInfo when constructed, which allocates multiple times.
• ShapeLineKey uses allocations that could be cached. It's also pretty expensive to hash.