Investigate perf/memory regression with components bag

[gregtatum]

Perf: https://unicode-org.github.io/icu4x-docs/benchmarks/perf/components/datetime/

Memory: https://unicode-org.github.io/icu4x-docs/benchmarks/memory/macos-latest/

My initial theories are that these examples are using JSON, which incurs a runtime penalty for loading the data providers compared to bincode. I believe this will mostly disappear with bincode support. One possible mitigation would be to move skeletons into their own key.

Here is the breakdown of the memory for the work_log: https://deploy-preview-3128--perf-html.netlify.app/public/37dy2yqktxz7jw6q8zx8eswg63zwy7jkg498kw0/flame-graph/?globalTrackOrder=0&localTrackOrderByPid=1511-0-1-2-3~&thread=0&transforms=mf-1~mf-2&v=5

icu_datetime::provider::gregory::patterns::_::::deserialize 42% 11.2KB

[zbraniecki]

One possible mitigation would be to move skeletons into their own key.

I'd support that. Seems like constructor knows whether we want skeletons or not, so being able to not load them should be a clean architectural division.

[gregtatum]

Looks like the difference in memory is nominal between bincode and json. This supports the case for separate keys.

JSON

		bytes	% Difference
main	Total	27,494	172%
	Global max	17,348	181%
	End	1,112	100%
pre-skeletons	Total	16,011
	Global max	9,583
	End	1,112

Bincode

		bytes	% Difference
main	Total	22,853	174%
	Global max	17,137	184%
	End	1,112	100%
pre-skeletons	Total	13,101
	Global max	9,305
	End	1,112

[gregtatum]

Looks like my theory on bincode is wrong here. I need to figure out how to collect a performance profile to see where time is being spent.

JSON

datetime/overview       time:   [1.4384 ms 1.4497 ms 1.4636 ms]
                        change: [+35.337% +38.009% +40.616%] (p = 0.00 < 0.05)
                        Performance has regressed.

Bincode

datetime/overview       time:   [963.59 us 968.30 us 973.42 us]
                        change: [+49.622% +51.380% +53.124%] (p = 0.00 < 0.05)
                        Performance has regressed.

[gregtatum]

I'm experimenting a bit with cargo instruments.

main/bincode

main/json

[gregtatum]

In the above profile, 60ms is spent in deserializing fields, which is probably where the performance regression is coming in from. This shows that splitting the keys is the fix here. Interestingly icu_datetime::provider::gregory::months is showing as being somewhat expensive to deserialize. Not sure what's going on there. The implementation is a bit obscured through macro magic that I did not untangle.

[sffc]

Blocked by #257 and #380

[dminor]

@gregtatum We plan to release 0.3 in about 3 weeks. Do you expect this to be unblocked in time for the 0.3 release, or should we punt to 0.4?

[dminor]

It looks like #380 is now planned for 0.4, can we remove that as a blocker?

[sffc]

Once I finish #257, @gregtatum should investigate if the issues are solved. If not, then we will need to wait for #380.

[gregtatum]

Resolved with #1139.

[gregtatum]

Latest benchmarks