Yeah. Swift is unique in that it features both incredibly slow compile times (in the good case, in bad cases it can abort due to timeouts on one line, 40 character expressions) AND slow runtime speed, especially when not optimising.
Code without the optimiser can easily be several hundred to more than a thousand times slower than optimised code. And of course the optimiser makes compile times even slower.
That's because Character is very, very different from ASCII in Swift (a character in Swift holds an extended grapheme cluster. See https://developer.apple.com/reference/swift/character). I also doubt the way they compute its ASCII value is optimal:
extension Character {
var asciiValue: UInt32? {
return String(self)
.unicodeScalars
.filter{$0.isASCII}
.first?
.value
}
}
Certainly if it is optimal, but probably also if it isn't, I would change the program to not do that conversion in inner loops.
Isn't the "scripting" part just automatically compiling behind the scenes before running? It's not an interpreter or a VM. So the code runs just as fast as the compiled version, it's just that you pay a startup cost.
That's true between a debug build and just running it as a script I believe. But a release version will be optimized, I imagine if they compared a debug build to the scripted version they'd perform similarly.
Yep totally, going to take another pass to try and make it faster. This was just a make it work experiment. Had a few fun troubles with random, but at the moment it just crawls :(.
starting from inside the arc4random call you have double float multiplication, then cast to uint32, then the arc4rand call, then the double cast for the uint32 result and then a double float division. this adds up in instructions.
Code without the optimiser can easily be several hundred to more than a thousand times slower than optimised code. And of course the optimiser makes compile times even slower.
It's really quite a spectacle.