[stdlib] Make some methods on Optional transparent

[karwa]

In unspecialised generic code (i.e. anything that isn't entirely @inlinable), this can make an enormous difference.

I’d appreciate somebody triggering benchmarks for this.

[karwa]

@lorentey you might be interested in this

[CodaFi]

@swift-ci test

[CodaFi]

@swift-ci benchmark

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - e49572b

[swift-ci]

Performance: -O

Improvement	OLD	NEW	DELTA	RATIO
FlattenListLoop	2508	1637	-34.7%	1.53x (?)
StringFromLongWholeSubstringGeneric	6	5	-16.7%	1.20x
FlattenListFlatMap	6648	5656	-14.9%	1.18x (?)
MapReduceAnyCollection	141	124	-12.1%	1.14x (?)
DictionaryOfAnyHashableStrings_lookup	4416	4056	-8.2%	1.09x (?)

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
ParseInt.IntSmall.Decimal	511	569	+11.4%	0.90x (?)
ParseInt.UIntSmall.Binary	685	758	+10.7%	0.90x (?)
ParseInt.IntSmall.UncommonRadix	568	626	+10.2%	0.91x
StrToInt	1940	2110	+8.8%	0.92x (?)
Improvement	OLD	NEW	DELTA	RATIO
StringFromLongWholeSubstringGeneric	6	5	-16.7%	1.20x
Data.append.Sequence.809B.Count.RE	114	101	-11.4%	1.13x (?)
DataAppendSequence	11200	10000	-10.7%	1.12x (?)
DictionaryKeysContainsCocoa	30	27	-10.0%	1.11x (?)
UTF8Decode_InitFromBytes_ascii_as_ascii	506	467	-7.7%	1.08x (?)
DictionaryOfAnyHashableStrings_lookup	4368	4080	-6.6%	1.07x (?)

Code size: -Osize

Performance: -Onone

Regression	OLD	NEW	DELTA	RATIO
Set.isStrictSuperset.Seq.Empty.Int	1409	1590	+12.8%	0.89x (?)
Dictionary2	1560	1695	+8.7%	0.92x (?)
Dictionary2OfObjects	4020	4335	+7.8%	0.93x (?)
Improvement	OLD	NEW	DELTA	RATIO
StringMatch	38900	31400	-19.3%	1.24x
SubstringTrimmingASCIIWhitespace	1643	1333	-18.9%	1.23x (?)
FindString.Rec3.String	796	660	-17.1%	1.21x
FindString.Rec3.Substring	749	628	-16.2%	1.19x
StackPromo	55600	46700	-16.0%	1.19x (?)
SevenBoom	1636	1412	-13.7%	1.16x (?)
NSStringConversion.MutableCopy.Rebridge.UTF8	1023	935	-8.6%	1.09x (?)

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - e49572b

[lorentey]

Interesting! It is usually better to go with @inline(__always) rather than @_transparent & so we’ve been trying not to use the latter unless there is a critical reason to do so. Can we also try a run with always-inlining instead?

[karwa]

My understanding is that @inline(__always) doesn’t inline at -Onone, so transparent would be required to remove these in debug builds.

The documentation (last I checked) said that transparent should be used for language features, that you don’t want to ever show up in stack traces. Optional.map is essentially the same as an if let, and it isn’t great that using one or the other produces much faster code. That goes for debug builds, but I’m sure I’ve seen it in unspecialised generic code at -O, too.

[eeckstein]

IMO, transparent is the wrong thing here. Those functions should not be hidden from debug info.
Performance wise, inline(always) should behave the same as transparent. Also, those functions are so small that the inliner should select them anyway, even without an inline(always).