Daniele Margutti

L'intuito mente: lezioni da un parser CSV — Parte 3: Il 9%

2026-09-14T00:00:00+00:00

Part 3 of 3

View all parts

Dove eravamo rimasti

Un parser che non si fa ingannare da una virgoletta in mezzo a un campo, costruito sopra un file mappato in memoria.

L'indicizzazione è scesa da 0,38 a 0,065 secondi grazie a memchr e a un controllo che decide da solo quando può permettersi la scorciatoia. Le righe non copiano un byte, e i campi si materializzano soltanto se qualcuno li chiede.

Tutto misurato, tutto più veloce di prima.

Tranne che non avevo mai cronometrato il lavoro completo.

Il 9%

Era giunto il momento di riprendere il cronometro in mano per misurare le fasi separatamente. Il trucco è far girare il ciclo con il corpo vuoto:

reader.forEachRow { _ in }

Questo divide ogni riga nei suoi campi e poi butta via tutto senza costruire un solo valore. La differenza fra questo tempo e quello del ciclo che fa davvero il lavoro è, per sottrazione, il costo della materializzazione degli oggetti.

Tre misure da prendere:

l’apertura del file
il ciclo a vuoto
il ciclo vero

The test: the pipeline broken down by phasesThe complete code is on GitHub, along with the file used for measurements.

@Test func stopTimes() throws {
    let clock = ContinuousClock()

    // Warm-up: one empty run brings the 260 MB into page cache.
    // Without it, the first measurement times the disk instead of the code—the same
    // read goes from ~0.19s to ~0.44s depending on whether pages are there or not.
    do {
        let warmup = try CSVReader(fileURL: gtfsURL, config: .init(hasHeaders: true))
        #expect(warmup.rowCount > 0)
    }

    // 1 — indexing (the init: mmap, sniff, scan for offsets)
    let rssBefore = residentMemoryMB()
    let t0 = clock.now
    let reader = try CSVReader(fileURL: gtfsURL, config: .init(hasHeaders: true))
    let indexing = clock.now - t0
    let rssAfterIndex = residentMemoryMB()

    guard let iTrip = reader.columnIndex("trip_id"),
          let iArr = reader.columnIndex("arrival_time"),
          let iDep = reader.columnIndex("departure_time"),
          let iStop = reader.columnIndex("stop_id"),
          let iSeq = reader.columnIndex("stop_sequence"),
          let iHead = reader.columnIndex("stop_headsign"),
          let iPick = reader.columnIndex("pickup_type"),
          let iDrop = reader.columnIndex("drop_off_type"),
          let iDist = reader.columnIndex("shape_dist_traveled"),
          let iTime = reader.columnIndex("timepoint")
    else {
        Issue.record("header diverso da quello atteso: \(reader.columnNames)")
        return
    }

    // 2a — just iteration: splitFields on every row, empty body.
    // Isolates the cost of splitting into fields from materializing values.
    var rowsVisited = 0
    let tSplit = clock.now
    reader.forEachRow { _ in rowsVisited += 1 }
    let splitOnly = clock.now - tSplit

    // 2b — direct access, building the exact same StopTime
    var builtDirectly = 0
    let t1 = clock.now
    reader.forEachRow { row in
        _ = StopTime(
            trip_id: row.field(at: iTrip),
            arrival_time: row.field(at: iArr),
            departure_time: row.field(at: iDep),
            stop_id: row.field(at: iStop),
            stop_sequence: row.intField(at: iSeq) ?? 0,
            stop_headsign: row.isFieldEmpty(at: iHead) ? nil : row.field(at: iHead),
            pickup_type: row.intField(at: iPick),
            drop_off_type: row.intField(at: iDrop),
            shape_dist_traveled: row.doubleField(at: iDist),
            timepoint: row.intField(at: iTime)
        )
        builtDirectly += 1
    }
    let direct = clock.now - t1

    // 2c — the same StopTime, but converting numbers by passing through String:
    // it's the obvious way, what you'd write without typed accessors.
    var builtViaStrings = 0
    let tStr = clock.now
    reader.forEachRow { row in
        _ = StopTime(
            trip_id: row.field(at: iTrip),
            arrival_time: row.field(at: iArr),
            departure_time: row.field(at: iDep),
            stop_id: row.field(at: iStop),
            stop_sequence: Int(row.field(at: iSeq)) ?? 0,
            stop_headsign: row.field(at: iHead).isEmpty ? nil : row.field(at: iHead),
            pickup_type: Int(row.field(at: iPick)),
            drop_off_type: Int(row.field(at: iDrop)),
            shape_dist_traveled: Double(row.field(at: iDist)),
            timepoint: Int(row.field(at: iTime))
        )
        builtViaStrings += 1
    }
    let viaStrings = clock.now - tStr

    // 3 — the same thing via Codable
    var decoded = 0
    let t2 = clock.now
    try reader.decode(StopTime.self) { _ in decoded += 1 }
    let codable = clock.now - t2

    #expect(rowsVisited == reader.rowCount)
    #expect(builtDirectly == decoded)
    #expect(builtDirectly == builtViaStrings)
    #expect(builtDirectly == reader.rowCount)

    let values = seconds(direct) - seconds(splitOnly)
    let valuesViaStrings = seconds(viaStrings) - seconds(splitOnly)

    print("""

    ── stop_times.txt — \(reader.rowCount) righe ──
      1. indicizzazione         \(indexing)   (RSS +\(String(format: "%.0f", rssAfterIndex - rssBefore)) MB)
      2a. solo splitFields      \(splitOnly)
      2b. + accessori tipizzati \(direct)
      2c. + conversione da String \(viaStrings)
      3. Codable                \(codable)

         dividere in campi        \(String(format: "%.3f", seconds(splitOnly)))s
         materializzare (tipizzati)  \(String(format: "%.3f", values))s
         materializzare (da String)  \(String(format: "%.3f", valuesViaStrings))s
         gli accessori tipizzati fanno risparmiare \(String(format: "%.1f", valuesViaStrings / values))x
         Codable costa \(String(format: "%.1f", seconds(codable) / seconds(direct)))x l'accesso diretto

    """)
}

Fase	Tempo	Quota
Indicizzazione	0,062s	9%
Dividere le righe in campi	0,260s	38%
Trasformare i campi in valori	0,427s	62%
Totale	0,687s

Mi ero concentrato a spremere 315 millesimi dall’indicizzazione per poi scoprire che gli altri 625 millesimi non li avevo mai guardati. Non è che avessi ottimizzato male: l’indice adesso è davvero cinque volte più veloce, e i numeri sono quelli. È che avevo ottimizzato con cura chirurgica la fase più piccola del programma, quella che nell’uso reale pesa meno di un decimo.

Questo per due motivi:

l’indice era la parte che vedevo: il codice appena scritto, quello che avevo in testa. Le altre due fasi funzionavano già e proprio per questo erano invisibili
l’indice era l’unico ad avere un numero: era facile da cronometrare, e quello che non ha un numero non compete per la nostra attenzione

All’inizio ho citato Knuth tagliando la parola premature. Ma la frase intera dice qualcosa di più specifico di quanto ricordassi:

«We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.»

Il 97% delle volte. Io ho trovato il mio 9% e mi ci sono buttato dentro con entusiasmo per tre sezioni.
La differenza fra me e quel consiglio non è che lui lo sapeva e io no: lo sapevo anch’io, l’ho scritto nell’introduzione di questo articolo.

È che sapere una cosa e averla misurata sono due stati mentali diversi, e solo il secondo cambia quello che fai il lunedì mattina.

Dividere i campi

Dai test era evidente come il 38% del tempo se ne andava a spezzare le righe nelle loro colonne. E’ qui che mi sono accorto che la risposta ce l’avevo già in casa ma l’avevo buttata via.

Se vi ricordate, all’apertura del file “annuso” le virgolette per decidere come costruire l’indice. Quel risultato (“questo file non contiene nemmeno una virgoletta”) lo usavo per una riga di codice e poi lo scartavo. In realtà può essere utile anche dopo: se non ci sono virgolette in tutto il file, allora quando divido una riga in campi ogni virgola che incontro è un separatore vero, senza eccezioni da controllare.

// `start` e `end` delimitano la riga da spezzare, `ranges` raccoglie i campi.
private func splitFields(start: Int, end: Int, into ranges: inout [Range<Int>]) {
    ranges.removeAll(keepingCapacity: true)

    // `hasQuotes` è l'esito dell'annusata fatta all'apertura del file.
    // Se è falso, in tutti i 260 MB non c'è una virgoletta: nessun campo
    // è quotato, e ogni virgola che incontro è un separatore vero.
    guard hasQuotes else {
        var fieldStart = start   // dove comincia il campo che sto leggendo
        var pos = start          // da dove riprendere a cercare

        // memchr cerca la prossima virgola fra `pos` e la fine della riga.
        // Il terzo argomento, `end - pos`, limita la ricerca a questa riga:
        // non può sconfinare in quella dopo.
        // Restituisce nil quando non ne trova più: siamo all'ultimo campo.
        while pos < end,
              let hit = memchr(base + pos, Int32(delimiterByte), end - pos) {

            // memchr restituisce un puntatore, a me serve una posizione:
            // la ottengo sottraendo l'indirizzo di partenza della mappa.
            let i = UnsafeRawPointer(hit) - UnsafeRawPointer(base)

            ranges.append(fieldStart..<i)   // il campo va da fieldStart alla virgola
            fieldStart = i + 1              // il prossimo comincia subito dopo
            pos = i + 1
        }

        // L'ultimo campo non ha una virgola che lo chiude: finisce con la riga.
        ranges.append(fieldStart..<end)
        return
    }

    // Il file contiene virgolette: non si scappa dalla macchina a stati,
    // byte per byte, con i quattro rami di prima.
}

Un 1,5x.
Mi aspettavo qualcosa di più.

Perché memchr questa volta non ci ha aiutati?

Ma perchè così poco, se sull'indice lo stesso approccio mi aveva portato un 5,7x? D'altronde era la stessa funzione, stesso file, stessa idea.

In fondo però il motivo è molto più semplice: memchr conviene quando il byte che cerchiamo è raro: carica sedici byte alla volta, li confronta tutti insieme, e ci guadagna finché continua a non trovare niente. Ogni chiamata ha però un costo fisso di avvio.

Sull'indice cercavo gli a capo: uno ogni quarantasei byte. Tempo per prendere il ritmo, e cinque milioni di chiamate in tutto.

Qui cerco le virgole: una ogni quattro byte e mezzo, e cinquantasei milioni di chiamate. memchr fa si e no un giro vettoriale e torna indietro. Di fatto è quasi il caso peggiore in cui può lavorare.

La stessa ottimizzazione, sugli stessi dati, vale cinque volte o una volta e mezza a seconda di quanto è fitto quello che stai cercando. Non esistono ottimizzazioni buone: esistono ottimizzazioni adatte a una certa forma dei dati.

A questo punto restava una una cosa evidente: per ogni campo facevo append su un array per cinquatasei milioni di righe, ognuno con il suo controllo di capacità e di unicità.

Toglierli sembrava facile: se l’array è già dimensionato sul numero di colonne dell’header, posso scrivere direttamente ranges[n] invece di accodare. L’idea era di recuperare fra 170 e 280 millesimi. Ne ho recuperati 48.

Anche qui un bel buco nell’acqua.

Perché togliere gli append non ha reso quasi niente

Il motivo è che davo a ogni append tre o quattro nanosecondi, e ne costava meno di uno. Con la capacità già riservata, in release il compilatore solleva quasi del tutto il controllo di unicità, e quello sulla capacità è un ramo che il predittore della CPU azzecca ogni singola volta.

In più, scrivendo ranges[n], un controllo l'ho semplicemente sostituito con un altro: quello sui limiti dell'array.

Comuque alla fine, con due mosse, ero passato da 0,484 a 0,275 secondi, guadagnando il 1,76x complessivo sulla divisione in campi.

Fase	Tempo	Quota
Indicizzazione	0,062s	8%
Dividere in campi	0,275s	35%
Trasformare i campi in valori	0,427s	57%
Totale	0,764s

Rimane soltanto la materializzazione dei valori che adesso è la parte più grossa del programma.
Ed è l’unica fase che non ho ancora toccato.

Da byte a valori

Per leggere i dati, come ad esempio il numero di sequenza di una fermata, la via più ovvia è quella di ottenere la stringa e fare il casting.

let n = Int(row.field(at: iSeq)) ?? 0

Questa innocua operazione ne nasconde però due: field(at:) prende i byte dal file mappato e ne costruisce una String; poi Int(_:) legge quella stringa e ne ricava un numero.
Un’istruzione dopo, la stringa non serve più a nessuno.

Mi sembrava evidente che il costo fosse lì: costruire un oggetto per buttarlo via subito, cinque milioni e mezzo di volte.
Così ho scritto un accessory che i byte li legge direttamente, senza che nessuna stringa venga mai creata.

Vale la pena guardare cosa significa, perché non è complicato.

In un file non ci sono numeri: ci sono byte. Prendete 74763, uno degli identificativi di fermata della riga d’esempio all’inizio dell’articolo. Sul disco non è il numero settantaquattromilasettecentosessantatré, sono cinque byte separati, uno per cifra, ciascuno con il codice del carattere corrispondente.

Per ricavarne un intero li si percorre uno alla volta ricostruendo il valore: si parte da zero, moltiplica per dieci, si aggiunge la cifra, si ripete. Cinque giri per questo campo soltanto, e una decina di campi per riga, su cinque milioni e mezzo di righe.

Perché non usare una funzione di sistema?

La libreria C ha strtol, che converte cifre in numeri lavorando direttamente sui byte grezzi: niente String di mezzo, ed è un candidato serio.

L'ho scartata per un motivo preciso: strtol vuole una sequenza terminata da uno zero, e i miei byte stanno in mezzo a un file mappato, dove dopo il campo c'è una virgola. In pratica funzionerebbe lo stesso, perché la funzione si ferma comunque al primo carattere che non è una cifra. Ma non è una garanzia scritta da nessuna parte, e c'è un caso cattivo: un numero all'ultimo byte di un file la cui dimensione sia un multiplo esatto della pagina. Lì leggere un byte oltre il campo significa leggere oltre la mappa, e sono di nuovo SIGBUS.

Non mi andava che la libreria funzionasse a patto che i file dei suoi utenti non fossero multipli di 16 KB.

Il parser a mano, invece, si ferma dove gli dico io:

var result = 0
var i = range.lowerBound

while i < range.upperBound {
    let digit = Int(base[i]) &- 48    // il carattere '0' vale 48
    guard digit >= 0, digit <= 9 else { return nil }

    // Un campo da trenta cifre non è impossibile in un file che non ho scritto io.
    // Con `result * 10 + digit` scritto in modo ingenuo, lì il processo muore.
    let (scaled, overflowA) = result.multipliedReportingOverflow(by: 10)
    guard !overflowA else { return nil }
    let (sum, overflowB) = scaled.addingReportingOverflow(digit)
    guard !overflowB else { return nil }

    result = sum
    i += 1
}

Le due righe sull’overflow meritano un attimo. La versione ovvia result = result * 10 + digit su un campo abbastanza lungo sfora la capacità di un Int, e in Swift sforare non dà un numero sbagliato: fa terminare il processo.
Le varianti ...ReportingOverflow costano quanto gli operatori normali, perché il controllo il compilatore lo genera comunque, ma restituiscono nil invece di ammazzare tutto.

Sui decimali la regola si inverte

Per i Double ho pensato di fare lo stesso, e ho fatto bene a fermarmi.
Scrivere un parser di virgola mobile corretto è una di quelle cose su cui esistono articoli scientifici: arrotondamento all’ultima cifra, notazione esponenziale, casi limite di precisione.
È il tipo di codice che sembra funzionare per sei mesi.

Quindi qui vince la libreria. Con una sorpresa: Double(String) di Swift non passa da strtod, ha un parser suo, e non dipende dalla locale. Il bug classico per cui su una macchina italiana 3.14 diventa 3, perché il separatore decimale atteso è la virgola, in Swift non esiste.

E la String che dovevo evitare a tutti i costi? Sotto i sedici byte Swift la tiene dentro la struct, senza toccare l’heap. 41.902782 sono nove caratteri: quella stringa vive nei registri e sparisce.

Quanto è servito

The test: the pipeline broken down by phasesThe complete code is on GitHub, along with the file used for measurements.

@Test func stopTimes() throws {
    let clock = ContinuousClock()

    // Warm-up: one empty run brings the 260 MB into page cache.
    // Without it, the first measurement times the disk instead of the code—the same
    // read goes from ~0.19s to ~0.44s depending on whether pages are there or not.
    do {
        let warmup = try CSVReader(fileURL: gtfsURL, config: .init(hasHeaders: true))
        #expect(warmup.rowCount > 0)
    }

    // 1 — indexing (the init: mmap, sniff, scan for offsets)
    let rssBefore = residentMemoryMB()
    let t0 = clock.now
    let reader = try CSVReader(fileURL: gtfsURL, config: .init(hasHeaders: true))
    let indexing = clock.now - t0
    let rssAfterIndex = residentMemoryMB()

    guard let iTrip = reader.columnIndex("trip_id"),
          let iArr = reader.columnIndex("arrival_time"),
          let iDep = reader.columnIndex("departure_time"),
          let iStop = reader.columnIndex("stop_id"),
          let iSeq = reader.columnIndex("stop_sequence"),
          let iHead = reader.columnIndex("stop_headsign"),
          let iPick = reader.columnIndex("pickup_type"),
          let iDrop = reader.columnIndex("drop_off_type"),
          let iDist = reader.columnIndex("shape_dist_traveled"),
          let iTime = reader.columnIndex("timepoint")
    else {
        Issue.record("header diverso da quello atteso: \(reader.columnNames)")
        return
    }

    // 2a — just iteration: splitFields on every row, empty body.
    // Isolates the cost of splitting into fields from materializing values.
    var rowsVisited = 0
    let tSplit = clock.now
    reader.forEachRow { _ in rowsVisited += 1 }
    let splitOnly = clock.now - tSplit

    // 2b — direct access, building the exact same StopTime
    var builtDirectly = 0
    let t1 = clock.now
    reader.forEachRow { row in
        _ = StopTime(
            trip_id: row.field(at: iTrip),
            arrival_time: row.field(at: iArr),
            departure_time: row.field(at: iDep),
            stop_id: row.field(at: iStop),
            stop_sequence: row.intField(at: iSeq) ?? 0,
            stop_headsign: row.isFieldEmpty(at: iHead) ? nil : row.field(at: iHead),
            pickup_type: row.intField(at: iPick),
            drop_off_type: row.intField(at: iDrop),
            shape_dist_traveled: row.doubleField(at: iDist),
            timepoint: row.intField(at: iTime)
        )
        builtDirectly += 1
    }
    let direct = clock.now - t1

    // 2c — the same StopTime, but converting numbers by passing through String:
    // it's the obvious way, what you'd write without typed accessors.
    var builtViaStrings = 0
    let tStr = clock.now
    reader.forEachRow { row in
        _ = StopTime(
            trip_id: row.field(at: iTrip),
            arrival_time: row.field(at: iArr),
            departure_time: row.field(at: iDep),
            stop_id: row.field(at: iStop),
            stop_sequence: Int(row.field(at: iSeq)) ?? 0,
            stop_headsign: row.field(at: iHead).isEmpty ? nil : row.field(at: iHead),
            pickup_type: Int(row.field(at: iPick)),
            drop_off_type: Int(row.field(at: iDrop)),
            shape_dist_traveled: Double(row.field(at: iDist)),
            timepoint: Int(row.field(at: iTime))
        )
        builtViaStrings += 1
    }
    let viaStrings = clock.now - tStr

    // 3 — the same thing via Codable
    var decoded = 0
    let t2 = clock.now
    try reader.decode(StopTime.self) { _ in decoded += 1 }
    let codable = clock.now - t2

    #expect(rowsVisited == reader.rowCount)
    #expect(builtDirectly == decoded)
    #expect(builtDirectly == builtViaStrings)
    #expect(builtDirectly == reader.rowCount)

    let values = seconds(direct) - seconds(splitOnly)
    let valuesViaStrings = seconds(viaStrings) - seconds(splitOnly)

    print("""

    ── stop_times.txt — \(reader.rowCount) righe ──
      1. indicizzazione         \(indexing)   (RSS +\(String(format: "%.0f", rssAfterIndex - rssBefore)) MB)
      2a. solo splitFields      \(splitOnly)
      2b. + accessori tipizzati \(direct)
      2c. + conversione da String \(viaStrings)
      3. Codable                \(codable)

         dividere in campi        \(String(format: "%.3f", seconds(splitOnly)))s
         materializzare (tipizzati)  \(String(format: "%.3f", values))s
         materializzare (da String)  \(String(format: "%.3f", valuesViaStrings))s
         gli accessori tipizzati fanno risparmiare \(String(format: "%.1f", valuesViaStrings / values))x
         Codable costa \(String(format: "%.1f", seconds(codable) / seconds(direct)))x l'accesso diretto

    """)
}

	Materializzazione
conversione da `String`	0,572s
accessori tipizzati	0,446s

Un 1,3x. Sul percorso completo, 1,18x..

Meno di quanto il ragionamento promettesse: il fatto è che la stringa che stavo evitando, in gran parte, non veniva allocata. I campi numerici di un CSV sono corti per natura, 1, 0, 1167, 07:30:00, quindi finiscono tutti dentro la soglia dei sedici byte e restano inline.

È la stessa scoperta che avevo appena fatto sui decimali dove ero convinto che il costo fosse l’allocazione. L’allocazione non c’era.

Il parser a mano resta la cosa giusta da avere, 1,3x è 1,3x, e una volta scritto non costa più niente, ma per una ragione diversa da quella per cui l’avevo scritto: non evita di allocare, evita di costruire e validare una stringa UTF-8 per poi scartarla un’istruzione dopo.

La regola d’oro qui è: crivilo a mano quando la grammatica è banale e la libreria generica ti chiede garanzie che non hai; usa la libreria quando la correttezza è difficile.
Ma soprattutto c’è bisogno di controllare cosa stai davvero risparmiando, perché nel mio caso non era quello che credevo.

Dove siamo arrivati

Questa è la fotografia finale, con i numeri dell’ultimo giro:

The test: the pipeline broken down by phasesThe complete code is on GitHub, along with the file used for measurements.

@Test func stopTimes() throws {
    let clock = ContinuousClock()

    // Warm-up: one empty run brings the 260 MB into page cache.
    // Without it, the first measurement times the disk instead of the code—the same
    // read goes from ~0.19s to ~0.44s depending on whether pages are there or not.
    do {
        let warmup = try CSVReader(fileURL: gtfsURL, config: .init(hasHeaders: true))
        #expect(warmup.rowCount > 0)
    }

    // 1 — indexing (the init: mmap, sniff, scan for offsets)
    let rssBefore = residentMemoryMB()
    let t0 = clock.now
    let reader = try CSVReader(fileURL: gtfsURL, config: .init(hasHeaders: true))
    let indexing = clock.now - t0
    let rssAfterIndex = residentMemoryMB()

    guard let iTrip = reader.columnIndex("trip_id"),
          let iArr = reader.columnIndex("arrival_time"),
          let iDep = reader.columnIndex("departure_time"),
          let iStop = reader.columnIndex("stop_id"),
          let iSeq = reader.columnIndex("stop_sequence"),
          let iHead = reader.columnIndex("stop_headsign"),
          let iPick = reader.columnIndex("pickup_type"),
          let iDrop = reader.columnIndex("drop_off_type"),
          let iDist = reader.columnIndex("shape_dist_traveled"),
          let iTime = reader.columnIndex("timepoint")
    else {
        Issue.record("header diverso da quello atteso: \(reader.columnNames)")
        return
    }

    // 2a — just iteration: splitFields on every row, empty body.
    // Isolates the cost of splitting into fields from materializing values.
    var rowsVisited = 0
    let tSplit = clock.now
    reader.forEachRow { _ in rowsVisited += 1 }
    let splitOnly = clock.now - tSplit

    // 2b — direct access, building the exact same StopTime
    var builtDirectly = 0
    let t1 = clock.now
    reader.forEachRow { row in
        _ = StopTime(
            trip_id: row.field(at: iTrip),
            arrival_time: row.field(at: iArr),
            departure_time: row.field(at: iDep),
            stop_id: row.field(at: iStop),
            stop_sequence: row.intField(at: iSeq) ?? 0,
            stop_headsign: row.isFieldEmpty(at: iHead) ? nil : row.field(at: iHead),
            pickup_type: row.intField(at: iPick),
            drop_off_type: row.intField(at: iDrop),
            shape_dist_traveled: row.doubleField(at: iDist),
            timepoint: row.intField(at: iTime)
        )
        builtDirectly += 1
    }
    let direct = clock.now - t1

    // 2c — the same StopTime, but converting numbers by passing through String:
    // it's the obvious way, what you'd write without typed accessors.
    var builtViaStrings = 0
    let tStr = clock.now
    reader.forEachRow { row in
        _ = StopTime(
            trip_id: row.field(at: iTrip),
            arrival_time: row.field(at: iArr),
            departure_time: row.field(at: iDep),
            stop_id: row.field(at: iStop),
            stop_sequence: Int(row.field(at: iSeq)) ?? 0,
            stop_headsign: row.field(at: iHead).isEmpty ? nil : row.field(at: iHead),
            pickup_type: Int(row.field(at: iPick)),
            drop_off_type: Int(row.field(at: iDrop)),
            shape_dist_traveled: Double(row.field(at: iDist)),
            timepoint: Int(row.field(at: iTime))
        )
        builtViaStrings += 1
    }
    let viaStrings = clock.now - tStr

    // 3 — the same thing via Codable
    var decoded = 0
    let t2 = clock.now
    try reader.decode(StopTime.self) { _ in decoded += 1 }
    let codable = clock.now - t2

    #expect(rowsVisited == reader.rowCount)
    #expect(builtDirectly == decoded)
    #expect(builtDirectly == builtViaStrings)
    #expect(builtDirectly == reader.rowCount)

    let values = seconds(direct) - seconds(splitOnly)
    let valuesViaStrings = seconds(viaStrings) - seconds(splitOnly)

    print("""

    ── stop_times.txt — \(reader.rowCount) righe ──
      1. indicizzazione         \(indexing)   (RSS +\(String(format: "%.0f", rssAfterIndex - rssBefore)) MB)
      2a. solo splitFields      \(splitOnly)
      2b. + accessori tipizzati \(direct)
      2c. + conversione da String \(viaStrings)
      3. Codable                \(codable)

         dividere in campi        \(String(format: "%.3f", seconds(splitOnly)))s
         materializzare (tipizzati)  \(String(format: "%.3f", values))s
         materializzare (da String)  \(String(format: "%.3f", valuesViaStrings))s
         gli accessori tipizzati fanno risparmiare \(String(format: "%.1f", valuesViaStrings / values))x
         Codable costa \(String(format: "%.1f", seconds(codable) / seconds(direct)))x l'accesso diretto

    """)
}

Fase	Tempo	Quota
Indicizzazione	0,064s	8%
Dividere le righe in campi	0,271s	35%
Trasformare i campi in valori	0,446s	57%
Totale	0,781s

La fase su cui ho lavorato di più, tre sezioni, quattro riscritture, mmap e memchr e l’annusata delle virgolette, è quella che pesa l’8%. Quella che ne pesa il 57% l’ho grattata una volta sola, per un 1,3x, e mi sono fermato lì.

Non perché sia la scelta giusta. Perché è dove sono arrivato.

E il confronto con cui abbiamo aperto

Undici secondi contro 0,34: quei 0,34 sono l’indicizzazione più la divisione in campi, cioè esattamente il lavoro che faceva la versione ovvia, leggere il file e spezzare ogni riga nelle sue colonne. Il confronto regge.

Costruire i valori tipizzati sopra è un lavoro in più che la versione ovvia non faceva affatto, e porta il totale a 0,781s. Se l’avesse fatto anche lei, i suoi undici secondi sarebbero stati parecchi di più.

I 250 MB

Anche l’altro numero dell’apertura merita una spiegazione, perché non è quello che sembra.

Dei 251 MB occupati, circa 45 sono l’indice: cinque milioni e mezzo di posizioni da otto byte l’una. Memoria vera, allocata da me, e l’unico punto del programma in cui la struttura dati costa più di quanto verrebbe da pensare. Con offset a 32 bit invece che a 64 sarebbero 22, al prezzo di rinunciare ai file oltre i 4 GB — un compromesso che non ho voluto fare, ma che è lì.

Gli altri 206 MB sono le pagine del file mappato, finite nel conteggio perché la scansione le tocca tutte. E qui la differenza con i 782 MB della versione ovvia non è solo di quantità: quelle pagine sono pulite, il kernel le può scartare gratis quando ha bisogno di spazio e rileggerle dal disco se servono ancora. Le stringhe della versione ovvia sono memoria sporca: o stanno in RAM, o finiscono in swap.

Due modi molto diversi di occupare un quarto di gigabyte.

Cosa mi porto via

Riguardando l’intera storia, la parte che mi resta non sono le ottimizzazioni.
Sono le volte in cui ero convinto di qualcosa e il cronometro ha detto un’altra cosa.

Ho creduto che il mio parser fosse lento e invece era il compilatore, in debug, a essere cinquantacinque volte più lento.
Ho creduto che mmap avrebbe accelerato la scansione e non l’ha accelerata di un millesimo.
Ho creduto che memchr avrebbe reso poco sui delimitatori e ha reso un 1,5x; poi ho creduto che togliere cinquantasei milioni di append avrebbe reso molto, e ha reso 48 millesimi.
Ho creduto che gli accessori tipizzati evitassero un’allocazione, e quell’allocazione non c’era mai stata.

Cinque previsioni, e quasi tutte sbagliate, alcune per eccesso, altre per difetto, il che almeno esclude che stessi barando a favore della mia tesi.

Quello che le ha smontate, ogni volta, non è stata l’esperienza o l’intuizione. È stato costruire la cosa che le avrebbe potute smentire: un benchmark, un test fatto per distinguere due guasti diversi, una tabellina su un foglio.

Non è che misurare renda più intelligenti. È che ti costringe a scoprire cosa stai davvero facendo, che di solito è un’altra cosa rispetto a quella che credevi.

Quello che resta sul tavolo

Il 57% della materializzazione è ancora lì e non l’ho quasi toccato. E c’è un salto più grosso che non ho nemmeno tentato: le righe sono indipendenti fra loro, grazie all’indice, e nessuna dipende da quella prima o da quella dopo. Su otto core quei 0,78 secondi potrebbero diventarne 0,14.

Ma lì entra (forse) in gioco SIMD, quindi il tetto lo fissa proprio la fase che vale l’8%.
È la storia delle prossime parti.

Part 3 of 3

View all parts

L'intuito mente: lezioni da un parser CSV — Parte 2: Corretto, poi veloce

2026-09-14T00:00:00+00:00

Part 2 of 3

View all parts

Dove eravamo rimasti

Un file GTFS da 260 MB, cinque milioni e mezzo di righe, e la scoperta che leggerlo costa l'1% del tempo: tutto il resto se ne va a trasformare byte in oggetti. Avevo preso tre decisioni di struttura (leggere a blocchi, indicizzare solo l'inizio delle righe, chiedere all'utente se c'è l'intestazione invece di indovinarla) e scritto la prima versione. Ci metteva venti secondi, quasi il doppio del codice ovvio, e non era colpa dell'algoritmo: era la build in debug.

In release erano 0,38 secondi. Il parser era veloce.

Restava da scoprire che non era corretto.

Quando una virgoletta fa sparire il file

Questa prima versione gestisce bene un a-capo tra virgolette quando queste racchiudono per intero il valore di una colonna.
Evitiamo infatti di interpretare il dato come la fine di una riga:

Mario,"Via Roma 1
00100 Roma",RM

Ma cosa succede se abbiamo " che non sono in un campo quotato?

prodotto,prezzo
monitor 24" full HD,199
tastiera,49

Quelle virgolette sono ovviamente i pollici dello schermo. Il nostro codice però vede una virgoletta e cambia stato di inQuotes. Mi sono scritto una tabellina a penna per chiarirmi il flusso: nessun benchmark, nessun test, solo quattro byte tracciati a mano su un file inventato di tre righe, ed è bastata a far crollare l’ipotesi.

Byte	`inQuotes` prima	Cosa fa
`\n` fine riga 1	`false`	registra la riga - OK!
`"` di `24"`	`false`	toggle → `true` - FAIL
`\n` fine riga 2	`true`	salta - SKIP
`\n` fine riga 3	`true`	salta - SKIP

Da quel momento in avanti il resto del file finisce per essere male interpretato e diventa pressoché spazzatura.

La buona notizia è che l’RFC del CSV ci dà una semplice regola per gestire il tutto: una virgoletta apre un campo quotato solo se è il primo byte del campo.

"Via Roma 1\n00100 Roma" la virgoletta è a inizio campo, il campo è quotato, l’a-capo dentro è un dato
monitor 24" full HD la virgoletta è a metà campo, quindi è solo un carattere

È il motivo per cui è necessario if atFieldStart.

Le virgolette raddoppiate si annullano da sole

Un altro caso potenzialmente da gestire erano le virgolette letterali. Dentro un campo quotato, una virgoletta letterale la si scrive raddoppiandola:

Mario,"disse ""ciao"" e se ne andò"

Verrebbe da gestirlo: vedo una virgoletta, sbircio la prossima, se è ancora una virgoletta allora è un escape.
In realtà non serve. Il toggle se la cava da solo:

"hello""world"
^                inQuotes = true
      ^          inQuotes = false
       ^         inQuotes = true    ← i due si annullano
             ^   inQuotes = false

Due cambi di stato consecutivi non cambiano niente, e lo stato finale è quello giusto.

Sembra un dettaglio, e invece è la cosa che tiene in piedi tutta la lettura a blocchi: senza sbirciare in avanti, il confine dei 64 KB smette di essere un caso speciale. Un “” a cavallo di due blocchi non va gestito, perché non esiste niente da gestire: il primo byte arriva in un blocco, il secondo nell’altro, e il conto torna comunque.

Se avessi scelto di sbirciare in avanti avrei dovuto gestire quel caso limite a mano, e i casi limite scritti a mano sono esattamente quelli che ci si perde più facilmente per strada.

Il test che parla chiaro

A questo punto c’è soltanto una cosa che lavora meglio di un debugger per validare il tutto, ed è un test:

The test: the newline inside quotesThe complete code is on GitHub, along with the file used for measurements.

// There are three \n in the bytes but only two real rows: the one at position 4 is inside quotes,
// and the final one produces a phantom row to discard.
// If you get [0, 5, 10] quote tracking isn't working at all;
// if you get [0, 10, 16] the phantom row isn't being discarded.
// The test tells apart the two failures, which is half its value.
@Test func indexIgnoreNewlineInsideQuote() {
    //          a  ,  "  x  \n y  "  ,  b  \n
    // indices  0  1  2  3  4  5  6  7  8  9
    let bytes = Array("a,\"x\ny\",b\n1,2,3\n".utf8)

    let offsets = bytes.withUnsafeBufferPointer { buf in
        CSVReader.indexLines(
            base: buf.baseAddress!,
            count: buf.count,
            quoteByte: 0x22,
            delimiterByte: 0x2C,
            trackQuotes: true
        )
    }

    #expect(offsets == [0, 10])
}

let bytes = Array("a,\"x\ny\",b\n1,2,3\n".utf8)
// indice:            0 1 2 3 4  5 6 7 8 9 …
#expect(offsets == [0, 10])

Tre \n nei byte, solo due righe sono vere: quello in posizione 4 è dentro le virgolette, e quello finale produce una riga fantasma da scartare.

Ma il valore del test non è nel controllo. È in cosa significano i modi di fallire:

Risultato	Diagnosi
`[0, 10]`	corretto
`[0, 5, 10]`	il tracciamento delle virgolette non sta girando affatto
`[0, 10, 16]`	gira, ma non scarta la riga fantasma finale

Due difetti diversi producono due numeri diversi. Il test non dice «sbagliato»: dice quale sbagliato.

E ha funzionato. Al primo lancio: [0, 5, 10].

Che è precisamente l’output di un parser che ignora le virgolette: quindi il problema non era la logica delle quote, era che quella logica non veniva eseguita. Sono andato a guardare il solo punto in cui poteva succedere, e il colpevole era un else scritto male:

} else {                  // scatta su qualunque byte
} else if !inQuotes {     // scatta solo fuori dalle virgolette

Il ramo dei separatori si attivava anche dentro un campo quotato. Un \n protetto dalle virgolette veniva registrato lo stesso. Il debugger non l’ho aperto.

A un test non chiedo di dirmi che ho sbagliato: quello lo so già.
Gli chiedo di dirmi dove.

L’ottimizzazione che non ha ottimizzato niente

A questo punto il parser generava correttamente un array con tutti gli indici di partenza delle righe.
Peccato che i dati, letti a blocchi da 64 KB, fossero già stati scartati: ogni blocco sovrascriveva il precedente.

Per estrarre davvero una riga dovevo tornare a prendermi quei byte, e le strade per farlo erano poche:

Rileggere riga per riga, saltando ogni volta alla posizione giusta: vuol dire una chiamata al sistema operativo per riga, sei milioni di chiamate per leggere in media quarantasei byte l’una. Decisamente da escludere.
Rileggere a blocchi e consegnare le righe man mano, ma vuol dire attraversare il file una seconda volta e rifare tutte quelle copie che volevo evitare. In più una riga può cominciare in un blocco e finire in quello dopo: per consegnarla intera devo conservare la coda del primo e attaccarla alla testa del secondo, con un caso speciale da scrivere e da ricordarsi. Anche questa poco attraente.
Mappare il file e tenermelo tutto indirizzabile in una volta.

Ed è qui che mi sono accorto di una cosa che avevo davanti dall’inizio: l’indice che avevo appena costruito contiene posizioni assolute dentro il file. Non sono offset relativi a un blocco, ma numeri che danno la posizione assoliuta.
Che è esattamente il linguaggio di una memoria mappata, dove il file è un array.

In effetti avevo già fatto metà del lavoro che rendeva mmap comodo:

let fd = open(fileURL.path, O_RDONLY)
defer { 
    // Una volta creata la mappa, il descrittore del file non serve più. 
    // La mappatura tiene un suo riferimento, e la memoria resta valida anche a file chiuso.
    close(fd)
}

var info = stat()
fstat(fd, &info)
let size = Int(info.st_size)

// mmap non dà i byte: riserva soltanto un intervallo di indirizzi nello spazio di memoria del processo 
// e dice al kernel «quando qualcuno tocca questi indirizzi, vai a prendere i pezzi di quel file». 
let mapped = mmap(nil, size, PROT_READ, MAP_PRIVATE, fd, 0)!
defer { munmap(mapped, size) } // rilascia la prenotazione alla fine

// crea il puntatore alla memoria tipizzato
let base = UnsafePointer(mapped.assumingMemoryBound(to: UInt8.self))

La parte di indicizzazione di colpo si era semplificata, senza il while, senza readData e senza dover mantenere un fileOffset.

Inoltre le tre variabili di stato, che erano fuori dal ciclo per tenere traccia tra una lettura e l’altra del blocco, ora erano normali variabili locale di un ciclo che percorre il file dall’inizio alla fine.
Il campo quotato spezzato a metà fra due letture, che non è stato risolto, aveva ha smesso di poter accadere.

var offsets: [Int] = [0]

var atFieldStart = true
var fieldIsQuoted = false
var inQuotes = false

for i in 0..<size {
    let b = base[i]
    // ...identico a prima, gli stessi quattro rami byte per byte
}

A parte la semplificazione del codice mi aspettavo però anche un miglioramento delle performance; ho quindi provato a misurare la differenza con la lettura a blocchi:

The test: three indexing stages comparedThe complete code is on GitHub, along with the file used for measurements.

@Test(.enabled(if: gtfsAvailable))
func stageComparison() throws {
    let clock = ContinuousClock()

    // Warm-up: pulls the 260 MB into the page cache, otherwise the first stage
    // measured is timing the disk and looks like the worst of the three.
    _ = try StageMemchr.indexLines(fileURL: gtfsURL)

    let t0 = clock.now
    let chunks = try StageChunks.indexLines(fileURL: gtfsURL)
    let chunksTime = clock.now - t0

    let t1 = clock.now
    let mapped = try StageMmap.indexLines(fileURL: gtfsURL)
    let mappedTime = clock.now - t1

    let t2 = clock.now
    let memchr = try StageMemchr.indexLines(fileURL: gtfsURL)
    let memchrTime = clock.now - t2

    // Again: same result, or the timings mean nothing.
    #expect(mapped == chunks)
    #expect(memchr == chunks)

    let attributes = try FileManager.default.attributesOfItem(atPath: gtfsURL.path)
    let gigabytes = Double((attributes[.size] as? Int) ?? 0) / 1_073_741_824

    func throughput(_ d: Duration) -> String {
        String(format: "%.2f GB/s", gigabytes / seconds(d))
    }

    print("""

    ── line indexing, \(chunks.count) rows ──
      1. 64 KB blocks       \(String(format: "%7.3f", seconds(chunksTime)))s   \(throughput(chunksTime))
      2. mmap               \(String(format: "%7.3f", seconds(mappedTime)))s   \(throughput(mappedTime))
      3. mmap + memchr      \(String(format: "%7.3f", seconds(memchrTime)))s   \(throughput(memchrTime))

         1 → 2: \(String(format: "%.1f", seconds(chunksTime) / seconds(mappedTime)))x
         2 → 3: \(String(format: "%.1f", seconds(mappedTime) / seconds(memchrTime)))x
         total: \(String(format: "%.1f", seconds(chunksTime) / seconds(memchrTime)))x

    """)
}

	Release
blocchi da 64 KB	0,384s
`mmap`	0,373s

Niente. Un uno virgola zero.

Neanche madvise(MADV_SEQUENTIAL) ha funzionato, ho rosicchiato giusto un altro centesimo.

Cos'è madvise()?

È un modo per dire al kernel come vogliamo usare una regione di memoria mappata, così che possa regolarsi di conseguenza. Con MADV_SEQUENTIAL stiamo dicendo «questo file lo leggerò dall'inizio alla fine, una volta sola».

Due cose cambiano. La prima è il readahead: quando tocchiamo una pagina, il kernel ne carica in anticipo anche un certo numero di quelle successive, invece di aspettare che gliele chiediamo una per una. Senza il suggerimento deve prima accorgersi da solo che stiamo procedendo in ordine, quindi parte più cauto.

La seconda è che le pagine che ci seiamo lasciati indietro vengono liberate prima, perché gli hai promesso che non tornerai a guardarle. Su un file da 260 MB è la differenza fra tenerselo tutto residente e tenerne una finestra che scorre.

È un suggerimento, non un ordine: il kernel può tranquillamente ignorarlo.

Che non abbia funzionato, comunque, ha perfettamente senso.

Pensandoci il collo di bottiglia non è mai stato il modo in cui i byte arrivano, ma il ciclo che ne guarda uno alla volta facendogli quattro domande. Ho cambiato come il file viene preparato, non come viene letto, e il tempo se ne andava tutto nella lettura.

Ora, tenersi una modifica che non fa guadagnare niente somiglia parecchio a un capriccio.
La differenza fra le due cose sta però tutta nel saper dire cosa ci ha comprato, anche quando non è velocità.

Qui erano meno codice e un caso limite in meno da ricordare, ma soprattutto un puntatore stabile: un indirizzo valido per tutta la vita del lettore, su cui potrò far puntare i campi senza doverli copiare da nessuna parte. A cosa serva davvero lo vedremo fra poco.

Per ora il cronometro segna 0,373 secondi, e non si è mosso di un millimetro.

Cercare invece di guardare

All’interno del mio ciclo di indicizzazione facciamo quattro domande per ogni byte.

Sono però domande che il più delle volte non servono a niente: la stragrande maggioranza dei byte sono dati, non caratteri di controllo (virgolette, virgole, a-capo).
Un sacco di domande la cui risposta non ci interessa, e che in ogni caso sarebbe “no”.

L’obiettivo era quindi evitare di esaminare ogni byte: bastava trovare il prossimo byte interessante nella sequenza.

Fortunamente il C ha da sempre una funzione dedicata: memchr prende un blocco di memoria e un byte, e restituisce la posizione della prima occorrenza. Dentro non c’è niente di magico, solo del codice scritto in SIMD a mano: invece di confrontare un byte alla volta ne carica sedici in un registro e li confronta tutti insieme.

SIMD? SIMD (Single Instruction, Multiple Data) è una tecnica di parallelismo a livello di microprocessore che consente di eseguire un'unica istruzione su un intero insieme di dati contemporaneamente, anziché elaborare un singolo dato alla volta. Solitamente scrivere codice SIMD non è la cosa più facile del mondo: fortunatamente qui il lavoro è già fatto ed è più veloce di qualunque ciclo che potrei scrivere in Swift.

C’è un problema, però, ed è grosso: memchr cerca un byte solo. Il mio parser non deve trovare un byte, deve sapere se in questo momento si trova dentro o fuori dalle virgolette. Quello è uno stato, e uno stato non si esprime con una ricerca.

La domanda che scioglie il nodo

Sembrava un vicolo cieco, finché non mi sono posto una domanda diversa: quand’è che lo stato non serve?

La risposta è quasi banale una volta detta: Se in tutto il file non c’è nemmeno una virgoletta, allora nessun campo può essere quotato. E se nessun campo è quotato, nessun a capo può trovarsi dentro un campo. Quindi cercare gli a capo e basta non è un’approssimazione: è dimostrabilmente corretto.

E per saperlo basta una memchr che cerchi una virgoletta sull’intero file.

// C'è almeno una virgoletta, in tutti i 260 MB?
let hasQuotes = memchr(base, Int32(quoteByte), size) != nil

guard hasQuotes else {
    // No. Allora nessun campo è quotato, e trovare gli a capo basta.
    var pos = 0
    while pos < size, let hit = memchr(base + pos, 0x0A, size - pos) {
        let i = UnsafeRawPointer(hit) - UnsafeRawPointer(base)
        offsets.append(i + 1)
        pos = i + 1
    }
    return offsets
}

// Sì. Allora serve la macchina a stati, byte per byte, come prima.

La parte che mi piace di più non è la velocità: è che non sto chiedendo niente a chi usa la libreria. Nessuna opzione da attivare, nessuna promessa da fare sui propri dati. Il codice guarda il file e decide da solo quale scorciatoia può permettersi.

Quanto ha reso

The test: three indexing stages comparedThe complete code is on GitHub, along with the file used for measurements.

@Test(.enabled(if: gtfsAvailable))
func stageComparison() throws {
    let clock = ContinuousClock()

    // Warm-up: pulls the 260 MB into the page cache, otherwise the first stage
    // measured is timing the disk and looks like the worst of the three.
    _ = try StageMemchr.indexLines(fileURL: gtfsURL)

    let t0 = clock.now
    let chunks = try StageChunks.indexLines(fileURL: gtfsURL)
    let chunksTime = clock.now - t0

    let t1 = clock.now
    let mapped = try StageMmap.indexLines(fileURL: gtfsURL)
    let mappedTime = clock.now - t1

    let t2 = clock.now
    let memchr = try StageMemchr.indexLines(fileURL: gtfsURL)
    let memchrTime = clock.now - t2

    // Again: same result, or the timings mean nothing.
    #expect(mapped == chunks)
    #expect(memchr == chunks)

    let attributes = try FileManager.default.attributesOfItem(atPath: gtfsURL.path)
    let gigabytes = Double((attributes[.size] as? Int) ?? 0) / 1_073_741_824

    func throughput(_ d: Duration) -> String {
        String(format: "%.2f GB/s", gigabytes / seconds(d))
    }

    print("""

    ── line indexing, \(chunks.count) rows ──
      1. 64 KB blocks       \(String(format: "%7.3f", seconds(chunksTime)))s   \(throughput(chunksTime))
      2. mmap               \(String(format: "%7.3f", seconds(mappedTime)))s   \(throughput(mappedTime))
      3. mmap + memchr      \(String(format: "%7.3f", seconds(memchrTime)))s   \(throughput(memchrTime))

         1 → 2: \(String(format: "%.1f", seconds(chunksTime) / seconds(mappedTime)))x
         2 → 3: \(String(format: "%.1f", seconds(mappedTime) / seconds(memchrTime)))x
         total: \(String(format: "%.1f", seconds(chunksTime) / seconds(memchrTime)))x

    """)
}

	Release
`mmap`, ciclo scalare	0,373s
`mmap` + annusata + `memchr`	0,065s

Un 5,7x, il primo vero salto di velocità.
C’è anche un effetto collaterale che non mi aspettavo. Prima dell’annusata avevo una variabile di configurazione — «prometto che nessun campo contiene a capo», che dava il percorso veloce a chi la attivava. Dopo, non serviva più a niente: la velocità arriva comunque. L’ho tolta.

E se avessi misurato in debug? Ricordate la figuraccia della build in debug? Vale la pena tornarci, perché questa ottimizzazione ci dà un altro punto di vista. Se avessi misurato questo stesso passaggio in debug, avrei visto un 176x invece di un 5,7x. Il motivo è che `memchr` è codice C già compilato, che la build di debug non tocca nemmeno, mentre il ciclo scritto a mano in Swift è precisamente ciò che il debug massacra.
Il confronto fra i due, in debug, è truccato in favore del primo di un fattore trenta.

Misurare nella configurazione sbagliata non dà soltanto il numero sbagliato, ma un suggerimento sbagliato di cosa convenga ottimizzare. Cosa che, come vedremo fra poco, è esattamente quello che avevo appena finito di fare.

Una riga che non contiene niente

A questo punto avevo ottenuto un codice più leggibile, meno flag di configurazione e non ultimo, la fase di indicizzazione era passata da 0,38s a 0,065s.

Batti il cinque! …Peccato che non sapessi come ottenere la riga numero n.

Due problemi, una soluzione

Prima di andare avanti abbiamo necessità di rappresenta è una riga. Potrebbe essere qualcosa di simile a questo?

struct CSVRow {
    let fields: [String] // i vari campi di ogni riga
}

potremmo leggerla con un cursore che avanza, una riga alla volta:

while let row = reader.nextRow() {
    print(row.field(at: 0))
}

È sicuramente l’approccio più semplice, ma anche il più costoso: per costruirla dovrei prendere i byte dal file, copiarli in una stringa nuova e metterla in un array.
Per ogni campo 56 milioni di stringhe, ognuna con la sua allocazione sull’heap.

Di fatto questo è l’approccio che si ottiene attraverso components(separatedBy:) e che avrebbe eclissato per tempi e consumi i piccoli passi di ottimizzazione fatti sopra.

Pensandoci però, i dati sono già in memoria: sono nel file mappato, contigui e già pronti. Vale davvero la pena copiarli per renderli visibili da un’altra parte?

struct CSVRow {
    let base: UnsafePointer<UInt8>  // il riferimento al file mappato
    let fields: UnsafeBufferPointer<Range<Int>>   // gli intervalli di ogni campo
}

In questa versione il testo della riga non viene mai copiato (zero-copy); si crea semplicemente una finestra su dati che sono già caricati altrove che vengono letti e processati solo nel momento in cui vengono richiesti (un po’ come fa Substring).

Ma anche questo approccio crea un problema: una riga che non contiene i propri dati è una riga che dipende da qualcun altro per restare valida in memoria; nel nostro caso dipenderà dall’esistenza della mappa nella classe CSVReader.

var riga: CSVRow?
do {
    let reader = try CSVReader(fileURL: url)
    riga = reader.nextRow()
} // qui il reader muore, e con lui la munmap
print(riga!.field(at: 0))   // SIGBUS

Il compilatore non segnalerà nulla ma a runtime la memoria non è più mappata e il processo muore con un SIGBUS.

Un secondo problema riguarda nuovamente le allocazioni.
Per dare accesso alle varie colonne per ogni riga c’è bisogno di un array di intervalli: un array per riga, cioè 5,6 milioni di altre allocazioni.

Suona familiare?
E’ esattamente il problema con cui siamo partiti all’inizio leggendo le righe, questa volta applicato alle colonne.

I due problemi hanno una radice comune: non c’è nessun momento in cui io sappia che una riga ha finito di servire. Se lo sapessi, potrei riusare lo stesso buffer per la riga successiva, e potrei garantire che nessuna riga sopravviva alla mappa. Quel momento me lo posso costruire, ed è la fine di una closure:

reader.forEachRow { row in
    // qui `row` è valida, e solo qui
} // qui non più

Dentro la closure il reader è vivo per definizione, quindi la mappa c’è.
E all’uscita so che quella riga è finita, quindi posso svuotare il buffer degli intervalli e riempirlo con la riga dopo.
Questo si traduce in una sola allocazione per l’intero file, invece di una per riga.

Il prezzo da pagare

Questa scelta ha un prezzo: si perde il while let, che è più familiare. Si perde l’uscita anticipata: per fermarsi alla prima riga che interessa serve un artificio, perché una closure che restituisce Void non sa dire «basta così» (nulla di complicato, qui, basterà far tornare un Bool in uscita).

Ovviamente niente mi vieta di catturare la riga dentro la closure e portarmela fuori, e se lo faccio torno al SIGBUS di prima. Per ora è una convenzione, non una regola: sta scritto nella documentazione, non nel compilatore. Swift avrebbe gli strumenti per renderlo un errore di compilazione, ma quella è una storia per un’altra volta.

A questo punto avevo tutto: un indice veloce, righe che non copiano niente, campi che si materializzano solo se qualcuno li chiede.
Mancava misurare quanto costasse davvero leggere quel file.

Part 2 of 3

View all parts