Faster Layout Nodes

[Adlai-Holler]

@appleguy @nguyenhuy Been majorly frustrated at work lately so it feels super good to have a nice, clean improvement to offer.

[Adlai-Holler]

Also for sugar on top, I was hoping to use QOS_CLASS_SOMETHING to specify the global queue there. The docs for dispatch_get_global_queue say You may specify the values QOS_CLASS_USER_INTERACTIVE, QOS_CLASS_USER_INITIATED, QOS_CLASS_UTILITY, or QOS_CLASS_BACKGROUND.. This feels like QOS_CLASS_UTILITY to me but I want to know what y'all think

[levi]

Awesome stuff, @Adlai-Holler!

[Adlai-Holler]

Thanks man!

[appleguy]

Create a local variable, CGSize calculatedSize = [node measureWithSizeRange:constrainedSize];

[Adlai-Holler]

Ah! Good point

[appleguy]

Very nice, thank you @Adlai-Holler! Some of @levi's changes are a possible performance regression in this code, but hopefully we can clean that up in the time before it lands — and having this as a higher bar will inspire us to do so :).

I would suggest we not touch queue priorities for now. The dispatch headers actually talk about the risk of priority inversion and in at least one place recommend not using priorities unless absolutely necessary. The main thread already runs at a higher priority, so there is no real risk of dropping frames from this background thread work. More importantly, if we run at lower priority, it's likely that arbitrary developers' own background tasks (compressing analytics data to send over the network, JSON parsing, etc) could be taking CPU time away from layout, which the user may well be waiting on (at the end of the scrollable area, awaiting for new cells to finish layout and be added).