Success Request List Performance Improvement

[alistairjevans]

Switched to tracking the 'next' position in the list, rather than resetting it.

Also experimented with the initial capacity. Ended up settling on an initial capacity of 32. It's a fair bit bigger than the default, but for complex graphs performance does improve some. I think it's worth the small amount of extra memory in simple graphs, to give us better performance in complex graphs.

Used the Deep Graph bench because that has a lot of requests in it.

Original (v6)

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
Resolve	18.37 us	0.135 us	0.120 us	4.1504	-	-	17.05 KB

Track Position

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
Resolve	17.57 us	0.189 us	0.177 us	4.1504	-	-	17 KB

Track Position + Allocate Custom Initial Capacity (12)

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
Resolve	17.62 us	0.123 us	0.109 us	4.1809	0.0305	-	17.16 KB

Track Position + Allocate Custom Initial Capacity (32)

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
Resolve	17.45 us	0.178 us	0.139 us	4.0894	-	-	16.71 KB

[tillig]

Interesting how little stuff like this can make a difference. I wish it was more "pit of success" than having to do weird workarounds like this, but I guess that's why they pay us the big bucks. (?)

[alistairjevans]

I guess 99.5% of developers just don't need to worry about performance to this degree, so the existing 'pit of basically fine' works well enough.

[tillig]

I'm absolutely working "pit of basically fine" into a presentation sometime in the near future.