Swift performance

Swift is competing with a good number of frameworks and languages. Some might argue that performance is only one out of many factors that should be considered when choosing a technology. While that is undoubtedly true, think of this: you want to build a project in a way where technology will not hold you back much. Facebook, as well as Uber, has spent years rebuilding and reworking their infrastructure. No matter what technology you choose, you will most likely refactor your application as well. However, having selected a stack that allows you to do so gracefully is crucial.

You could be looking at some raw benchmarks in this section, but I think it makes more sense to analyze with a bit more depth what performance holistically looks like for a project. When comparing Swift to its competition, you want to stay as clean and objective as possible; the following comparisons attempt to assess the situations objectively and as close to the real world as possible.

Almost any website can run with any of the languages available. The question is often not "Is it possible?" but rather "Does it make sense for us?". In some cases, speed and performance are more important than convenience. In other cases, it's the exact opposite.

Let's briefly dig into the following types of languages:

• Scripting languages: PHP, Python, Ruby, JavaScript, and so on
• Virtual machine languages: Java, .NET, and Scala
• Native languages: Go, C, Rust, and Swift

Afterward, you will see some metrics of Vapor, the most popular Swift framework.

Scripting languages

Script languages are not being compiled into a native binary but interpreted on-the-fly. So, every request to the server is treated individually and mostly isolated. The server then calls the language interpreter to work through the requested file (index.php, for example). Every time a script is called the server program needs to be started again. Naturally, this is not the fastest way to respond to a request.

A lot of mechanisms to speed up this process were invented over the years. All of them are essentially trying to do the following:

• Cache interpreted code.
• Cache various outputs and inputs as a whole.
• Reduce the amount of overhead.

A lot of optimization for these languages is solely the idea of caching what they have compiled already and then returning it from caches when appropriate. There is principally nothing wrong with this approach, but it makes it difficult to compare performance. You want to assume the worst scenario, which is an empty cache when evaluating the pure speed of an application. Caching can be added later—even to an already speedy application.

The most popular scripting languages include Ruby, Python, PHP, JavaScript, and Typescript. All of them have various environments and interpreters, some of which are faster than others. They all share that they are naturally not compiled into binary code and will consequently always fall behind native languages. On the other hand, they enjoy a rich community and have gained many fans due to their simplicity.

Let's look at some real-life examples of websites dealing with scripting languages.

Facebook

Facebook started all in plain PHP and over a decade came up with its own PHP-flavored server called Hack. Hack started out as an initial attempt to compile PHP to a native binary file. It failed, however, due to the unforeseeable internal structure of a PHP program (dynamic variables, inconsistencies, and so on). Hack ended up being a PHP version that was modified to fit Facebook's internal needs. However, Hack is now running as a Virtual Machine (VM), not as a native application.

The reasons for Facebook were that it wanted to keep its dependencies and existing libraries operational while also increasing performance. While Facebook shows that scripting languages can certainly get very performant, it also shows how discontented Facebook became over time with PHP.

Twitter

Twitter started, like Facebook, as a monolithic application. It was written as a Ruby-on-Rails application. However, the increase in traffic caused Twitter to rewrite its backend entirely using the Java Virtual Machine (JVM), which means programming languages such as Java, Scala, and Clojure were used. Twitter also specifically attributes the microservice architecture as part of its path forward with regards to meeting traffic needs.

Read https://www.slideshare.net/caniszczyk/twitter-opensourcestacklinuxcon2013 for more detailed information on Twitter's stack.

Uber

Uber has transitioned critical services from Python to Go by now. In this case, it was partially for performance, but not in the same way Facebook was affected. Uber needed some of its services to be fast, concretely, live position updates. Uber chose Go because it was able to get better performance.

It is interesting to see how big players have started to transition some of their services from scripting languages to native ones.

Let's explore VM languages next.

VM languages

The most commonly used language in this category is Java. JVM has a long track record for being an enterprise-class web technology. On the other hand, .NET by Microsoft allows you to write in a variety of languages; often, C# stands out as the most common one for server applications.

Right between JVM and .NET is Scala—which is a new language that can compile into either .NET or JVM.

VM languages have the advantage that they are pre-compiled. They are not interpreted on-the-fly like scripting languages but pre-compiled into VM-specific byte code, which is then run on the VM. It comes with a good performance boost.

Apple, IBM, and LinkedIn are three examples that are using Java in a lot of their infrastructure.

Because VM code runs on the actual VM, and the engine is an extra layer on top of the operating system, VMs typically need a lot of RAM to operate smoothly. It is very common for the JVM to run on multiple GBs of RAM even for relatively simple applications.

Read https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf for more information on JVM RAM usage.

Native languages

Swift is a native language that compiles into native apps! So are C and C++. C (and C++) is inevitably the fastest language because it is so close to machine code (leaving Assembler aside). Many scripting languages directly plug into C for this reason. Node.js, PHP, and Python often directly utilize C functions, and those will always be very fast. Naturally, a pure C server will be the fastest server you could develop.

So, why not write our servers in C, you might ask? The reason you don't necessarily want to do that is that C is not convenient or safe in terms of memory leaks. It is complicated (some say impossible) to write good memory-safe programs in C. For web projects, this problem leads to the creation of Go (sometimes referred to as Golang), Rust, and Swift. All three were invented with the thought in mind to keep the performance of C/C++ but get better memory safety.

Go and Rust kept a mostly C-like functional style whereas Swift got inspirations from other object-oriented languages such as Java and scripting languages such as Ruby and Python. All three languages compile into native code, which means they run faster by default than the other two types of languages. No clear metric would show if any of the three is faster than the others. A good programmer could probably create equally performant programs in either language.

All three languages have been picked up by major players for critical performance tasks. For Swift, big players using it for web services include the following:

• Apple
• IBM
• Mercedes
• Audi

The main reason Swift is exciting to big corporations is that a native application leaves a much smaller RAM footprint. Imagine what difference it can make if you can achieve the same results but only need 25% of your hardware.

Comparing frameworks

As said before, it is not easy to compare languages, let alone frameworks, to each other. One framework might be extremely fast in doing one job whereas completely slow in another position. The following metrics have been recorded with Vapor 3 and a few other frameworks. Take them with a grain of salt, and as technologies continually develop, don't use them as hard numbers because any software update can change the balance:

(Source: https://medium.com/@codevapor/vapor-3-0-0-released-8356fa619a5d)

It shows how all three Swift frameworks perform well compared to other well-known frameworks. You can see that the Swift frameworks outperform the other frameworks, except for Go, quite significantly. The scripting languages do not perform well as they are not natively compiled. The key to performance is that Swift compiles natively and can run directly on the processor.

We have looked at the frameworks and Swift's performance overall, so let's look at some specific Swift features now.

Swift's features

Here is a summary of all of the things that make Swift an attractive choice for server development:

• A modern language built with the modern paradigm
• A native language with native performance
• Very low RAM usage
• Linux-friendly
• Universal usage can create apps for other OSes as well

There are certain situations and ways in which other languages are faster than Swift; however, overall, Swift offers the most significant performance benefits through its native design and low RAM footprint. Let's now explore what Swift looks like on a server.