5
\$\begingroup\$

To compare ergonomics and performance of some languages for my hobby projects, I have written a simple lines of code counter in Swift, Go, Rust and Python. It scans a given directory tree for source code files and then prints a summary of the number of files, lines of code and lines of comments.

The result surprised me: Swift was by far the slowest of them all.

Am I doing something obvious wrong, or is Swift generally not a good language for this task?

Scanning my entire development directory on macOS 15.5 (M1 Max):

These are all "naive" implementations without any form of optimization on my part. I suspect Go did some parallelization automatically, because it showed more than 100% CPU usage when timeing it.

main.swift:

import Foundation

struct StandardError: TextOutputStream, Sendable {
    private static let handle = FileHandle.standardError

    public func write(_ string: String) {
        Self.handle.write(Data(string.utf8))
    }
}

var stderr = StandardError()

// don't scan these directories
let IGNORED_DIRS = [
    "__pycache__",
    "node_modules",
]

// mapping source file type to comment strings
let FILE_TYPES = [
    "c":      ("//", "/*", "*/"),
    "c++":    ("//", "/*", "*/"),
    "cpp":    ("//", "/*", "*/"),
    "go":     ("//", "/*", "*/"),
    "h":      ("//", "/*", "*/"),
    "hs":     ("--", "{-", "-}"),
    "js":     ("//", "/*", "*/"),
    "kt":     ("//", "/*", "*/"),
    "pro":    ("%",  "/*", "*/"),
    "ps1":    ("#",  "<#", "#>"),
    "py":     ("#",  "",   ""  ),
    "rs":     ("//", "/*", "*/"),
    "sql":    ("--", "/*", "*/"),
    "svelte": ("//", "/*", "*/"),
    "swift":  ("//", "/*", "*/"),
    "ts":     ("//", "/*", "*/"),
]

struct Counts {
    var files = 0
    var code = 0
    var comments = 0
}

extension Counts: CustomStringConvertible {
    var description: String {
        String(format: "%6d %16d %20d", files, code, comments)
    }
}

func handleScanError(url: URL, error: Error) -> Bool {
    print("Error: Couldn't scan directory '\(url)': \(error)", to: &stderr)
    return true
}

func isSourceFile(_ file: URL) -> Bool {
    FILE_TYPES.keys.contains(file.pathExtension)
}


if CommandLine.argc < 2 {
    print("Usage: loc <file or directory>...", to: &stderr)
    exit(1)
}

// collect source files
let clock = ContinuousClock()
var start = clock.now

var sourceFiles = Set<String>()

let fm = FileManager.default

for arg in CommandLine.arguments[1...] {
    let root = URL(filePath: arg)

    guard (try? root.resourceValues(forKeys: [.isDirectoryKey]))?.isDirectory == true else {
        if isSourceFile(root) {
            sourceFiles.insert(arg)
        } else {
            print("Warning: '\(arg)' is not a source file", to: &stderr)
        }
        continue
    }

    guard let directoryEnumerator = fm.enumerator(at: root, includingPropertiesForKeys: nil, errorHandler: handleScanError) else {
        print("Couldn't enumerate directory '\(root)'", to: &stderr)
        continue
    }

    for case let path as URL in directoryEnumerator {
        guard let resourceValues = try? path.resourceValues(forKeys: [.nameKey, .isDirectoryKey]), let isDirectory = resourceValues.isDirectory, let name = resourceValues.name else {
            print("Couldn't get resource values for '\(path)'", to: &stderr)
            continue
        }

        if isDirectory {
            // skip unwanted dirs
            if name.starts(with: ".") || IGNORED_DIRS.contains(name) {
                directoryEnumerator.skipDescendants()
            }
        } else {
            if isSourceFile(path) {
                sourceFiles.insert(path.path(percentEncoded: false))
            }
        }
    }
}

var end = clock.now
print("DEBUG: Total collecting all source files: \(end - start)")

// scan files
start = clock.now
var parseDuration = Duration.zero
var scanDuration = Duration.zero

var counts: [String: Counts] = [:]

for file in sourceFiles {
    let ext = URL(filePath: file).pathExtension
    let (commentLine, commentStart, commentEnd) = FILE_TYPES[ext]!
    let hasBlockComments = commentStart != "" && commentEnd != ""
    var isBlockComment = false

    let time1 = clock.now

    guard let text = try? String(contentsOfFile: file, encoding: .utf8) else {
        print("Error: failed to read file as utf8 '\(file)'", to: &stderr)
        continue
    }

    var c = counts[ext] ?? Counts()
    c.files += 1

    let time2 = clock.now

    for line in text.components(separatedBy: .newlines) {
        let l = line.trimmingCharacters(in: .whitespaces)

        if l.isEmpty {
            continue
        }

        if hasBlockComments {
            if isBlockComment {
                c.comments += 1
                if l.contains(commentEnd) {
                    isBlockComment = false
                }
                continue
            }

            if l.hasPrefix(commentStart) {
                c.comments += 1
                if !l.contains(commentEnd) {
                    isBlockComment = true
                }
                continue
            }
        }

        if l.hasPrefix(commentLine) {
            c.comments += 1
            continue
        }

        c.code += 1
    }

    counts[ext] = c

    let time3 = clock.now

    parseDuration += time2 - time1
    scanDuration += time3 - time2
}

end = clock.now

// print results
print("           files    lines of code    lines of comments")

var totals = Counts()

for (ext, c) in counts {
    print(".\(ext.padding(toLength: 8, withPad: " ", startingAt: 0)) \(c)")
    totals.files += c.files
    totals.code += c.code
    totals.comments += c.comments
}

print("──────────────────────────────────────────────────────")
print("total     \(totals)")

print("DEBUG: Reading files as UTF8: \(parseDuration)")
print("DEBUG: Scanning line by line: \(scanDuration)")
print("DEBUG: Total iterating over source files: \(end - start)")

Output:

> swiftc -O -o loc main.swift
> time ./loc ~/Developer
DEBUG: Collecting files: 0.26490225 seconds
           files    lines of code    lines of comments
.ps1           4              131                   90
.swift       428            20685                 1696
.svelte      136             6376                  671
.pro           4              194                    9
.go           95             8624                  411
.sql           1                8                    0
.js          105            33755                 4062
.rs          185            14857                  540
.kt           15              566                  102
.cpp           6              761                  197
.h           130           204362                34138
.hs            4              130                   21
.py         5781          1873424               137586
.ts           42            14030                  367
.c           166           211577                45105
──────────────────────────────────────────────────────
total       7102          2389480               224995
DEBUG: Reading files as UTF8: 0.148959414 seconds
DEBUG: Scanning line by line: 2.191142604 seconds
DEBUG: Total iterating over source files: 2.357491542 seconds
./loc ~/Developer  2.38s user 0.25s system 99% cpu 2.634 total

Edit: adding source code for the other implementations for comparison. Again: these are all unoptimized, "naive" implementations. I kept the structure and logic of all programs as close to each other as possible.

Edit 2:

In my experiments, using fopen() and getline(), as per Martin R's answer, was the only thing that made the Swift program faster. On my machine Swift now takes 1.6s (Python 1.0s).

For me, the conclusion is that Swift is not worth it for my projects. I can get similar performance by writing trivial Python code (I had to do no performance-troubleshooting at all there). Or I can write Go code which is still relatively simple and much faster (and probably has potential to be made even faster if it's needed). It makes me a bit sad, because I enjoy writing Swift a lot.

\$\endgroup\$
6
  • \$\begingroup\$ Did you profile your code with Instruments? My guess would be that much time is spent in the for line in text.components ... loop. \$\endgroup\$ Commented Jul 17 at 20:59
  • 1
    \$\begingroup\$ Could you post/link to your python or rust impl? It's a bit hard to guess where the difference between known and unknown code lies. \$\endgroup\$ Commented Jul 17 at 23:05
  • \$\begingroup\$ @MartinR I used Instruments, but I couldn't make much sense of it. That's why I added all those print debug statements with timings. Have a look at the output example I posted. Indeed most of the time is spent scanning files line by line. \$\endgroup\$ Commented Jul 18 at 5:39
  • \$\begingroup\$ @STerliakov I've added links to the source code of the implementations in Python, Go and Rust. \$\endgroup\$ Commented Jul 18 at 5:40
  • \$\begingroup\$ @flitzer: I can reproduce that the Swift program is slower than the Python program, but more like 20% slower. Did you run the program multiple times with the same results? \$\endgroup\$ Commented Jul 18 at 8:50

4 Answers 4

Reset to default
1
\$\begingroup\$

Before addressing the performance issues I'd like to make some suggestions concerning the overall structure of the program. There is far too much code in the “main” program, making it difficult to read, test, or debug.

The essential part of the top-level code could be as short as

var sourceFiles: [URL] = []

for arg in CommandLine.arguments[1...] {
    collect(url: URL(fileURLWithPath: arg))
}

for file in sourceFiles {
    process(file: file)
}

printResults()

Your program uses a set of strings (file names) to stores the list of source files:

var sourceFiles = Set<String>()

I would use URLs instead to avoid the conversions from URL to String and back. Duplicates in that list can only occur if the directories or files specified on the command line overlap. If that is not an issue then an array is slightly more performant.

An alternative would be to scan each source file immediately during the directory enumeration, making the sourceFiles set or array obsolete. That might be faster for huge directory trees.

Then we have one function for handling each command line argument:

func collect(url: URL) {
    guard let resourceValues = try? url.resourceValues(forKeys: [.isDirectoryKey]),
          let isDirectory = resourceValues.isDirectory else {
        print("Couldn't get resource values for '\(url)'", to: &stderr)
        return
    }
    if isDirectory {
        collect(directory: url)
    } else {
        if isSourceFile(url) {
            sourceFiles.append(url)
        } else {
            print("Warning: '\(url)' is not a source file", to: &stderr)
        }
    }
}

and another function for enumerating a directory tree:

func collect(directory: URL) {
    guard let directoryEnumerator = fm.enumerator(at: directory,
                                                  includingPropertiesForKeys: [.nameKey, .isDirectoryKey],
                                                  options: .skipsHiddenFiles,
                                                  errorHandler: handleScanError) else {
        print("Couldn't enumerate directory '\(directory)'", to: &stderr)
        return
    }
    
    for case let path as URL in directoryEnumerator {
        guard let resourceValues = try? path.resourceValues(forKeys: [.nameKey, .isDirectoryKey]),
              let isDirectory = resourceValues.isDirectory,
              let name = resourceValues.name else {
            print("Couldn't get resource values for '\(path)'", to: &stderr)
            continue
        }
        if isDirectory {
            // skip unwanted dirs
            if name.starts(with: ".") || IGNORED_DIRS.contains(name) {
                directoryEnumerator.skipDescendants()
            }
        } else if isSourceFile(path) {
            sourceFiles.append(path)
        }
    }
}

Finally, a function to scan a source file:

func process(file: URL) {
    // ...
}

This is where most of the work is done. As already mentioned in other answers, your code reads the entire file into one String and then creates lots of Strings, one for each line. Profiling the program with Instruments shows that much time is spent in

text.components(separatedBy: .newlines)

There are various resources with recommendations how to parse a file more efficiently in Swift. On Stack Overflow there is, for example (already mentioned in another answer):

and there are probably more. There is also

in the Swift forum, and again, there are more.

From my experiments:

  • Swift.split(separator:maxSplits:omittingEmptySubsequences:) creates an array of SubStrings, which are references into the orignal string. That saves some copies, but is not much faster.
  • The URL.lines method reads lines asynchronously. That might be an advantage if the data is read from an asynchronous connection, but I could not observe an advantage when reading from plain files (more the opposite).

It seems that for the best performance one has to use good old standard I/O methods like fopen(), getline(), fgets() etc. Apple engineer “Quinn “The Eskimo!” says here:

If you read a file line-by-line, it’s critical to do user-space buffering to avoid hitting the kernel for each line. Swift doesn’t have that facility, and neither does Foundation.

Implementing line buffering yourself (on top of, say, InputStream or FileHandle) is quite tricky. Rather than rolling my own, I typically use the C standard library for this. That is, I use FILE * with a Swift wrapper.

Here is an example how this could be used in the process(file:) function:

func process(file: URL) {
    // ...
    
    // Open file, make sure that it is closed on function exit.
    guard let fd = fopen(file.path, "r") else {
        print("Error: failed to open '\(file)'", to: &stderr)
        return
    }
    defer { fclose(fd) }
    
    var c = counts[ext, default: Counts()]
    c.files += 1

    // Pointer to line buffer, so that they are reused between `getline` calls:
    var lineBuffer: UnsafeMutablePointer<CChar>? = nil
    var lineCap: Int = 0
    
    while case let length = getline(&lineBuffer, &lineCap, fd), length > 0 {
        let line = String(cString: lineBuffer!)
        let l = line.trimmingCharacters(in: .whitespacesAndNewlines)
        if l.isEmpty {
            continue
        }

        // Process `l` as before ...
    }
    free(lineBuffer)

    counts[ext] = c
}

With these modifications, the Swift program is about as fast as the Python program in my tests.

Some further remarks:

  • Avoid too short variable names like c and l.
  • One can subscript a dictionary with a default value: counts[ext, default: Counts()], similar to counts.get(ext, Counts()) in Python.
  • The .skipsHiddenFiles option of the directory enumerator should make the test for name.starts(with: ".") obsolete.
\$\endgroup\$
2
  • \$\begingroup\$ Thank you for the extensive analysis. I like your suggestions regarding the code organization. About the performance: I tried most things you linked (see also my comments on STerliakov's answer). They were all slower. Async especially was horribly slow (mentioned in one of your links also). I'm shying away from Unsafe* - it doesn't seem "swifty". If I need to jump through so many hoops to get performance similar to Python (I expected better), it's simply not worth it for me. \$\endgroup\$ Commented Jul 18 at 13:17
  • \$\begingroup\$ @flitzer: Yes, it is a pity that Swift does not offer an efficient way to parse text files (at least none that I am aware of). There may be something in the SwiftNIO library, but I am not familiar with that. \$\endgroup\$ Commented Jul 18 at 13:26
4
\$\begingroup\$

streaming results

Your python code probably uses ‘os.walk’ straight from the man page, and so gets to overlap sys mode time in the kernel with user mode time in the app. This facilitates read ahead prefetch, so tasks overlap their execution.

And you can filter as you go.

In contrast the OP swift code first reads all files into a giant malloc’d space, and then starts filtering and processing. Prefer a streaming pipeline for your next swift implementation.

\$\endgroup\$
2
  • \$\begingroup\$ Yes, I use os.walk in Python. However I collect all files in a set first, and only then do I iterate over the set elements. I kept all implementations very basic and following the same procedure. As I understand, directoryEnumerator (Swift) also filters while traversing. Do you have a hint for streaming in Swift? I'd like to look into that. \$\endgroup\$ Commented Jul 17 at 15:40
  • \$\begingroup\$ @MartinR So does my Python script. It collects them in a set of strings, then iterates over the set and does with open(file) as f: where file is a string (full path). I understand this can be optimized. My point is I want to understand why Swift is so much slower than even Python, when I'm doing the same thing in all programs. \$\endgroup\$ Commented Jul 17 at 20:45
2
\$\begingroup\$

Note: I did not look at other languages yet, only Swift and Python. Another note: I speak Python and Rust and know ~nothing about Swift, I only follow its docs and don't even have the toolchain installed.

You say that your python version is ~2.5x faster. Here's why: it does not read the whole file into memory!

for line in file:

This is usually correct and often the fastest way. And incidentally it's not what your Swift code does.

Fair comparison with String construction followed by splitting lines into an array (your swift code, and this is probably the heaviest part involving a ton of allocations) would be

for line in file.read().splitlines():

which should be much slower (and please don't use that in real code, at least do file.readlines() if you really need all lines in memory at once - that avoids double alloc - and plain iteration over file handle is better if you don't need them all at once like here).

Now let's look at the Swift counterpart:

    guard let text = try? String(contentsOfFile: file, encoding: .utf8) else {
        continue
    }

    for line in text.components(separatedBy: .newlines) {

uh-oh. You first read the whole string into memory. Then you split it (method docs) into an array. Nothing is lazy here, so you allocated a string for the whole file, then thousands of strings for every line in that file (and still keep them all in memory), and only then started iterating.

Doing the same in python (file.read().splitlines()) makes it complete in 9.7 seconds instead of 3.9 (averaged over 3 runs) on my PC for one folder.

To make this less resource-intensive in Swift, you might want to at least use .split with omittingEmptySubsequences: false instead of .components - its docs say something about "subsequences" which sounds like non-copies. (take this part with a grain of salt, again, I know nothing about Swift). Answers to this question suggest a bunch of other ways, some of them might be closer to python's for line in handle. And this one looks even better.

String::lines in Rust returns an Iterator (there's a Lines struct for that which is an implementation detail, the only important thing is that it does not create an array of all components at once), so you take no double alloc penalty there either. You only read the whole file and then efficiently iterate over the result, only holding a copy of a single line (or no copies at all) - that's likely comparable with buffered reads unless your files are really huge.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks, I'll look into those linked Stackoverflow answers. However I already tried .split(separator: "\n", omittingEmptySubsequences: true) before and it is slower than my current solution (takes about 3.2s instead of 2.6s). \$\endgroup\$ Commented Jul 18 at 11:50
  • \$\begingroup\$ Ok, the first reasonable looking and modern way was actually my inital implementation: for try await line in fileUrl.lines. It was terribly slow (~20s). I just now tried Martin R's answer from the second link (StreamReader) and it is also slower than my current code (4.2s). \$\endgroup\$ Commented Jul 18 at 13:05
1
\$\begingroup\$

The parser does not handle all combinations of block comments and code correctly. For example:

  • Block comments are not recognized if they are preceded by code:

      int x = 0; /*
    comment
   */

    is counted as three lines of code and no comment lines.

  • Code is not recognized if it follows a block comment on the same line:

      /*
    comment
   */ int x = 0;

    is counted as zero lines of code and three comment lines.

\$\endgroup\$
2
  • \$\begingroup\$ I know ;) The logic is oversimplified. It's not meant to be a tool for others to use. Its sole purpose is to test how convenient and performant each of the chosen languages are for such programs. There already exist many code counters with far more features and correct counting out there. \$\endgroup\$ Commented Jul 23 at 6:04
  • \$\begingroup\$ Btw, correctly counting in all supported languages is extremely tricky. There are tons of execeptions to handle like when comment characters appear in strings, docstrings, multiline-strings etc. You basically have to write a simple parser for each language. \$\endgroup\$ Commented Jul 23 at 6:10

You must log in to answer this question.