Performance advantage of ContiguousArray

Development Standard Library
,
1

From Writing High-Performance Swift Code, section Using Container Types Efficiently, Advice: Use ContiguousArray with reference types when NSArray bridging is unnecessary:

If you need an array of reference types and the array does not need to be bridged to NSArray, use ContiguousArray instead of Array:

class C { ... }
var a: ContiguousArray<C> = [C(...), C(...), ..., C(...)]

I wonder if this advice still holds, because after suggesting some potential performance improvements to two Sequence slicing operations following the SE-0234 acceptance, I have tried using ContiguousArray as an alternative type to standard Array in some upcoming benchmarks. I saw no performance difference even on reference types.

This might be (I hope) because the optimizer does equally good job with Array now. Is there a test scenario that can demonstrate ContiguousArray giving better performance than Array? I'm asking because I'd like to use it in SBS benchmarks.

On the other hand there have been reports of edge cases where ContiguousArray performs worse than Array: SR-7637.

So I wonder how to properly test if following the example from map and filter to internally use ContiguousArray will be beneficial for suffix and drop(last:).

2 Likes
2

I would come down on the side of never use ContiguousArray. On Linux there’s no reason to ever invoke its name, and on OSX you really have to make an effort to get it to diverge from Array. If you ask me it really shouldn’t even be in the language.

Someone should really go through the rest of that document too as I’m sure most of that advice is way past its expiration date. I remember a lot of the ARC tips don’t apply anymore ever since they changed the ownership passing convention (they seem to be gone now which is good)

3 Likes