| My (highly speculative) guess is that your String issues were due to either/both: - Swift performance issues involving working with strings, some of which have been ameliorated by later releases; - 'Hidden' bridging between NSString and String, which can be expensive and might have something to do with some of String's APIs actually being Foundation APIs in disguise. There is much to be done with regards to Swift performance, though. If you have any sample benchmarks I would be interested in writing/running them myself, just for personal edification. In terms of 'close to the metal', I freely admit this is a ill-defined term I am using for my own benefit. Swift code doesn't execute on something akin to the JVM or CLR; it still requires a heavier runtime than (e.g.) Rust. It is AOT-compiled to machine code. (But then again, this is possible to some degree for Java as far as I can tell, although it is certainly not the most popular way to run Java code.) I agree that mandatory RC for classes and boxed types makes Swift impractical for a certain definition of 'systems software' typically written in C++ and occasionally Rust. For a different definition, one that encompasses the garbage-collected Go, Swift is theoretically suitable. The language designer has mentioned that he would personally like to see Swift gain some form of borrowing/lifetimes, although even if that did happen Swift would not get it for years to come. |
The simplest benchmark I used is a function that does the equivalent of
So it splits a string around a separator and removes any whitespace around the items. For a million strings the numbers I get are as follows:Swift: 3.5 seconds
Java: 0.31 seconds (after warmup)
So that makes Java more than 10 times as fast as Swift.
Here's the source code. I would be more than happy if you could tell me that I'm doing something horribly wrong (which I frequently do):
And here's the Java code: