You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now, let's add one character and watch the world go up in flames:
structHasAnEnum {
// ...varvalue: MyEnum? // <- Make this an optional
}
output.test(output.HasAnEnum) -> Swift.Int:
push rbx
sub rsp, 16
add rdi, 160
lea rbx, [rsp + 8]
mov rsi, rbx
call (outlined init with take of output.MyEnum?)
mov rsi, rsp
mov rdi, rbx
call (outlined init with take of output.MyEnum?)
movzx eax, byte ptr [rsp]
mov ecx, eax
and ecx, 1
cmp rax, 2
lea rcx, [rcx + 4*rcx - 1]
mov rax, -1
cmovne rax, rcx
add rsp, 16
pop rbx
ret
Boom. Now we're calling a bunch of runtime functions, and this code suddenly performs much worse while also being much larger.
In my code, this is a major performance issue. It dominates almost everything else we do... just to load a stored optional enum.
(This trace is from a function which writes a normalized URL string using scanned ranges from an input string. As you can see, the only thing more expensive than this is parsing/writing the path string, which has to simplify arbitrarily long and complex paths and percent-encode them. That's how expensive it is).
In fact, >8% of the time spent writing the URL string is the load of this one optional. Wild.
The text was updated successfully, but these errors were encountered:
Environment
Swift version 5.6-dev (LLVM 70b82c8b83f6294, Swift a66435c)
Target: x86_64-unknown-linux-gnu
Additional Detail from JIRA
md5: 8c58205ab47b0a9798dd31351dc797cd
Issue Description:
Consider the following code:
In an optimised build, this generates the following assembly (Godbolt):
Short, sweet. Just what you'd expect, right?
Now, let's add one character and watch the world go up in flames:
Boom. Now we're calling a bunch of runtime functions, and this code suddenly performs much worse while also being much larger.
In my code, this is a major performance issue. It dominates almost everything else we do... just to load a stored optional enum.
(This trace is from a function which writes a normalized URL string using scanned ranges from an input string. As you can see, the only thing more expensive than this is parsing/writing the path string, which has to simplify arbitrarily long and complex paths and percent-encode them. That's how expensive it is).
In fact, >8% of the time spent writing the URL string is the load of this one optional. Wild.
The text was updated successfully, but these errors were encountered: