I'm confident I've been able to found the root cause, no fix yet.
It's easy to reproduce: start new instance, grab resize handle and resize away.
I'm looking right now at a trace 23.3 seconds long trace. It has:
I think that overall slowness comes from that and fragmentation that comes with it. After some time I can imagine it's difficult to grab a 2KiB slot from OS.
The outliers seems to be drawing glyphs, but I wouldn't focus on it first.
IMO there are two root causes:
I'll try do deliver some prototype, but I'm not sure if that'd be anything integration-worthy.
Best,
Przemysław Alexander Kamiński
Most allocation-heavy stacktrace tail (count is total allocations in the inspected, 10s long frame):
2 172166 ns_draw_glyph_string_foreground [inlined] emacs emacs/src/nsterm.m:4278
1 172166 macfont_draw emacs emacs/src/macfont.m:2951
Transient allocations trace excerpt:
1878.09 MB 100.0% 1613815 emacs -[EmacsApp run]
1874.40 MB 99.8% 1576278 emacs -[EmacsApp sendEvent:]
1653.78 MB 88.0% 644420 emacs -[EmacsView layoutSublayersOfLayer:]
24.48 MB 1.3% 184083 emacs -[EmacsWindow setFrame:display:]
44.38 MB 2.3% 143554 emacs -[EmacsView windowWillResize:toSize:]
200.22 KB 0.0% 2237 emacs -[EmacsView mouseMoved:]
17.88 KB 0.0% 520 emacs -[EmacsWindow constrainFrameRect:toScreen:]
7.72 KB 0.0% 494 emacs -[EmacsLayer display]
25.00 KB 0.0% 480 emacs -[EmacsApp stop:]
77.17 KB 0.0% 177 emacs -[EmacsView viewDidEndLiveResize]
14.62 KB 0.0% 78 emacs ns_send_appdefined
20.58 KB 0.0% 68 emacs -[EmacsView windowDidResignKey:]
14.09 KB 0.0% 213 emacs -[EmacsLayer display]
5.73 KB 0.0% 65 emacs -[EmacsWindow accessibilityAttributeValue:]
192 Bytes 0.0% 1 emacs ns_send_appdefined