Open dabrahams opened 7 years ago
@swift-ci create
Turns out the comment below is bogus; it was avoiding work by shifting the buffer length out of its UInt8
and thus the buffer became magically empty. So feel free to delete this from the bug.
Even weirder: take that commit and add work by changing the getter/setter for _bitsInBuffer
as follows:
var _bitsInBuffer : UInt8 {
get { return buffer._length >> 3 }
set { buffer._length = newValue << 3 }
}
Now I see across-the-board speedups for both test cases of approximately 17.5%:
.h3 Without Shifting
set -e
for x in FORWARD REVERSE ; do
echo $x
swiftc -DBENCHMARK -D$x -O -swift-version 4 UnicodeDecoders.swift -o /tmp/u3-$x
for i in {1..3}; do
time nice -19 /tmp/u3-$x
done
done
-----
FORWARD
real 0m2.643s
user 0m2.628s
sys 0m0.007s
real 0m2.643s
user 0m2.626s
sys 0m0.009s
real 0m2.640s
user 0m2.627s
sys 0m0.007s
REVERSE
real 0m2.413s
user 0m2.400s
sys 0m0.007s
real 0m2.412s
user 0m2.400s
sys 0m0.006s
real 0m2.420s
user 0m2.408s
sys 0m0.007s
.h3 With Shifting
set -e
for x in FORWARD REVERSE ; do
echo $x
swiftc -DBENCHMARK -D$x -O -swift-version 4 UnicodeDecoders.swift -o /tmp/u3-$x
for i in {1..3}; do
time nice -19 /tmp/u3-$x
done
done
-----
FORWARD
real 0m2.170s
user 0m2.156s
sys 0m0.006s
real 0m2.200s
user 0m2.183s
sys 0m0.008s
real 0m2.191s
user 0m2.174s
sys 0m0.009s
REVERSE
real 0m1.957s
user 0m1.943s
sys 0m0.006s
real 0m1.960s
user 0m1.949s
sys 0m0.007s
real 0m2.035s
user 0m2.008s
sys 0m0.011s
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug, Performance | |Assignee | None | |Priority | Medium | md5: 8bf5b601c5998b28eb72814a42a69846Issue Description:
Note: this is very close to github/master, with no changes except in test/Prototypes/
build the compiler with the following command
Note: the difference described here is only a few percent
Then enter the test/Prototypes directory and execute:
recording the output.
Now do the same thing after checking out that commit's parent, 1ab347c66bc517c2e62aee56d8f569ebcf1a8fa7
I notice that the first run is reliably a few percent slower than the second. This really shouldn't be the case because the HEAD commit does nothing but wrap a
UInt32
and aUInt8
into astruct
with just about everything inlined. The properties are then re-exposed as computed and all computation proceeds exactly as before.Other hashes