-rw-r--r-- 919B Jun 14, 2017 · 5C60537 · ~2 min

Benchmarks: Vapor 2 vs. Vapor 1

swift backend vapor ubuntu

After migrating my pet project from Vapor 1 to Vapor 2 I've run benchmarks to compare performance. I didn't run benchmarks for the last version of Vapor 1.x which is 1.5.15 so I will compare Vapor 2.1.0 to results of Vapor 1.2.5 that I have from my last results.

My server:

  • 2 GB RAM
  • 1 CPU Core
  • SSD
  • 125 MBPS Out
  • Ubuntu 16.04.2 LTS
  • CouchDB

Benchmark from other server was launched as:

wrk -t4 -c20 -d5m https://my_url

API just gets some data from CouchDB and returns it as JSON. Vapor project has been compiled with Swift 3.1.1.

[↵] open page benchmarks-vapor-2-vs-vapor-1.md
-rw-r--r-- 1.8K May 3, 2017 · 6BC24C7 · ~2 min

Weak delegate in Swift 3

swift шпаргалки утечки памяти

Memory usage in Xcode

I was fighting memory leaks in a work project. Digging led me to the fact that after leaving a UIViewController, far from all memory gets released. If you open this UIViewController several times, go back, and open it again, memory consumption grows and does not get released very much.

The root of the problem turned out to be protocols and delegates. A classic mistake. In my UIViewController I use a UICollectionView with a custom cell that has a delegate. My UIViewController is the delegate for each cell. An example of implementing such a protocol and delegate on the internet and in a Swift book looks roughly like this:

// Protocol
protocol MyCollectionViewCellDelegate {
    func someFunc()
}

// UICollectionViewCell
final class MessageCollectionViewCell: UICollectionViewCell {
    var delegate: MyCollectionViewCellDelegate?
}

// UIViewController
func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
    // some code....
    cell.delegate = self
}

Inside the cell object we have a strong reference to the delegate (UIViewController), which results in a memory leak.

The solution is simple — make the reference to delegate weak. To do that, you have to specify that only a class can implement the protocol. Structures are out, but there is no need for them here anyway. It changes like this:

// Protocol
protocol MyCollectionViewCellDelegate: class {
    func someFunc()
}

// UICollectionViewCell
final class MessageCollectionViewCell: UICollectionViewCell {
    weak var delegate: MyCollectionViewCellDelegate?
}

After these simple changes everything became great — after navigating back from the UIViewController, memory usage returns to its initial level.

[↵] open page weak-delegate-v-swift-3.md
-rw-r--r-- 8.5K Mar 24, 2017 · B3FBAC0 · ~7 min

Impressions of Assassin's Creed Syndicate

assassin's creed игры

Assassin's Creed Syndicate

[↵] open page vpechatleniya-ot-assassin-s-creed-syndicate.md
-rw-r--r-- 6.5K Feb 28, 2017 · 3EB5FBA · ~5 min

Impressions of Assassin's Creed Rogue

assassin's creed игры

Assassin's Creed Rogue

I finished another installment, Assassin's Creed Rogue.

[↵] open page vpechatleniya-ot-assassin-s-creed-rogue.md
-rw-r--r-- 1.1K Feb 9, 2017 · F3580BC · ~1 min

Space In Box Website

swift приложения space in box vapor

Space In Box website

I decided to move the information about my apps from apps.arm1.ru to a separate domain. Since I once started publishing them under the name Space In Box, the domain matches: spaceinbox.me. I decided to remove apps that were no longer relevant or available and use vector graphics as much as possible everywhere (icons, logos), because on Retina screens raster graphics really hurts the eyes.

It was a great excuse to build something in Swift with the Vapor framework, and so far everything I needed worked out. Updating it when something changes in the logic is of course harder, because you have to rebuild everything on the server each time, and that takes 3–4 minutes every time. But if it concerns only the layout (tweaking html), the templates are picked up by the binary on the fly and there is no need to recompile. The speed and memory usage (8.8 MB so far) are pleasing. Now I can update old apps and ship new ones.

UPDATE: With a simple update to Vapor 1.5.14, without changing any code, the site started using even less memory — 6.7–7.7 MB.

[↵] open page sajt-space-in-box.md
-rw-r--r-- 1.1K Dec 8, 2016 · B2818A9 · ~2 min

Benchmarks for Vapor 1.2.5

swift backend vapor ubuntu

About a month ago I launched benchmarks for Server side Swift frameworks. Yesterday I updated my project to the new version of Vapor: 1.2.5. Previous version I used was 1.1.11.

One of the most important updates in Vapor 1.2.x is that Vapor is now using a non-blocking server.

So today I decided to run a new benchmark for my project updated to Vapor 1.2 and results surprised me. It's not only faster than the 1.1.x version, it's now equal to Node.js results!

Vapor vs. Node.js

My server:

  • 2 GB RAM
  • 1 CPU Core
  • SSD
  • 125 MBPS Out
  • Ubuntu 16.10
  • CouchDB

Benchmark from other server was launched as:

wrk -t4 -c20 -d5m https://my_url

API just gets some data from CouchDB and returns it as JSON.

[↵] open page benchmarks-for-vapor-1-2-5.md
-rw-r--r-- 1.5K Nov 12, 2016 · A3940ED · ~2 min

Swift Backend with CouchDB: Kitura vs. Vapor vs. Node.js

swift backend vapor kitura ubuntu

I made a few test projects to implement an API for my simple app to run some benchmarks. It just makes 1 request to Database and returns JSON data.

All projects was executed on Linode VPS in London:

  • 2 GB RAM
  • 1 CPU Core
  • SSD
  • 125 MBPS Out
  • Ubuntu 16.10
  • MySQL and CouchDB with equal data (about 13k rows/documents)

Benchmarks was run on another, more powerful dedicated server in Germany using wrk:

wrk -t4 -c20 -d5m https://my_url

Results are very different from other benchmarks by Ryan Collins.

What did I try:

  • Node.js 7.0 + MySQL 5.7.16
  • Node.js 7.0 + CouchDB 2.0 (via node-couchdb)
  • Vapor 1.1.11 + CouchDB 2.0 (via HTTP)
  • Kitura 1.1.1 + CouchDB 2.0 (via Kitura-CouchDB)

Total requests

Requests per second

Average Latency

Results are very disappointing for me. Node.js was 50% faster than Swift. It looks like it's still not the right time to make backends on Swift right now, unless you don't expect high load and just want to write in Swift.

UPDATE: after about a month I ran another tests for the new version of Vapor (1.2.5) vs. Node.js and Vapor was very very fast. So now I'm very optimistic about using Swift as a backend.

[↵] open page swift-backend-with-couchdb-kitura-vs--vapor-vs-node-js.md
makoni@arm1:~/blog$ cd ../page-9/ // ← previous cd ./page-11/ // more posts →