Speeds up the unicode scalar view around 20%. Now we are reasonably confident
we don't need a more sophisticated API for decoding than the one we've got, and
can move toward integration.
Reverse iteration over a collection is significantly slower than forward.
REVERSE_COLLECTION
user 0m4.609s
user 0m4.587s
user 0m4.585s
COLLECTION
user 0m3.423s
user 0m3.517s
user 0m3.492s
A really simpleminded Collection view is faster by far than trying to cache all
that information.
I believe we could do even better by storing a simpler cache in the indices of
the view, but performance is already in decent shape, so we can put off
further optimization:
BASELINE
user 0m2.864s
user 0m2.775s
user 0m2.763s
SEQUENCE
user 0m2.632s
user 0m2.571s
user 0m2.553s
COLLECTION
user 0m3.553s
user 0m3.567s
user 0m3.475s
Implements Sequence and Collection views over arbitrary CodeUnits, demonstrating
that indexing is possible. However, collection-style decoding is approximately
3x slower than sequence-style, because Decoders have a fundamentally
Sequence-oriented interface. I think I know what needs to be done to get
parity.
This finally makes us measurably faster than the BASELINE, existing code in
master:
BASELINE
user 0m2.869s
user 0m2.890s
user 0m2.893s
FORWARD
user 0m2.727s
user 0m2.730s
user 0m2.737s
REVERSE
user 0m2.417s
user 0m2.418s
user 0m2.416s
Use something a little higher-level for buffering bytes, so we can give the
Decoder's buffer a Collection requirement, on the way to building indexable
transcoded collections.
For now, we're still reaching into our high-level data structure's stored
properties rather than using its API.
Having looked at the old transcoding code, it's very clear that no stateless
scheme has a hope of competing with it on performance. We just need reverse
transcoding and a way to hook up indices (I believe we can use IndexingIterator
for this, that's coming).
This code demonstrates UTF-8 (the hard one) and is competitive on performance
with the existing code. I believe it could be even better-performing if the
cases that do parsing were connected directly with the cases that do decoding.
Finally, tatoo this on your forehead: Dmitri Shall Not Be Underestimated
In Swift 3 shifts used to be defined on the concrete integer types, so
the right-hand-side value in the shift expression could define a type
for the result, as in `1 << i32` would have the type Int32. Swift 4
makes shift operators heterogeneous, so now `1 << i32` will result in an
Int, according to the type of the left-hand-side value, which gets a
default type for integer literals.
When enumerating same-type-to-concrete requirements, don't emit a
same-type-to-concrete requirement for a nested archetype anchor when
it's parent also is equivalent to a concrete type, because the former
can always be derived from the latter.
Fixes SR-4456 / rdar://problem/31286125.
