Swift 6's concurrency support/non mutable Element

[Ceylo]

Hello,

I'm giving a try to Swift 6 and have to import SwiftSoup with @preconcurrency for now as it's not yet ready.
One case I have is this method:

extension Collection where Element: Sendable {
    func parallelMap<T: Sendable>(_ transform: @Sendable @escaping (Self.Element) throws -> T) async rethrows -> [T] {
        try await withThrowingTaskGroup(of: (Int, T).self) { group in
            for (offset, element) in enumerated() {
                group.addTask {
                    (offset, try transform(element))
                }
            }
            
            return try await group
                .reduce(into: [T?](repeating: nil, count: count),
                        { $0[$1.0] = $1.1})
            as! [T]
        }
    }
}

Which I then use to transform Elements provided by SwiftSoup:

async let nodes = elements.parallelMap { element in ... }

From what I understand, since Element is mutable (and thus not Sendable), the Swift compiler has no way to know that parallelMap won't mutate it from another concurrent context, while the calling context may also mutate it.
Could we have in the future some API providing sendable Elements?

Thank you!

[aehlke]

I'll merge a PR for this if you have a solution in mind

[DarkDust]

Some notes from #318 and recent development: the Node class (and thus Element) is currently inherently mutable and changing that would require a tremendous amount of work. It was marked @unchecked Sendable for some time but that was removed since it simply wasn't thread-safe at all.

@Ceylo , can you describe your use-case for needing parallelised processing of a document's elements? Is the work you're trying to do so expensive that sequential processing is too costly? Would you be able split it up into a sequential pre-processing phase, where you evaluate the document, deriving some sendable data from that, and do parallel processing on that sendable data?

[Ceylo]

I'm using SwiftSoup to parse webpages from an artists social network.
Artists galleries contain about a hundred of items per page.
I also parse the user's personal received messages and notifications. There're about 50 messages per page and 75 notifications per page. The initial (biggest part) is parsing the whole HTML page with SwiftSoup and selecting all the messages or notifications. Then each message or notification is an independent SwiftSoup.Element that can be further processed in parallel to extract the final per-item data.

Parsing 50 messages takes about 20ms when parallelized on my 6 cores iPhone 13 Pro. Based on the signposts I have, the cumulated time on a single thread would be ~110ms. CPU Profiler tells me that 91% of that time is spent in Element.select(), so I'd definitely be affected if I made SwiftSoup work single-threaded. This is without taking into account the initial single-thread part which is just asking SwiftSoup to parse the whole page to extract the relevant nodes and takes 47ms.

Similarly, parsing 75 notifications takes 8.6ms and would take 40ms on a single thread and 90% of the CPU time is in SwiftSoup, with an already existing initial step of 41ms for the global page parsing.

If you want to see how it's done:

• page parsing: https://github.com/Ceylo/FurAffinityApp/blob/main/FAKit/Sources/FAPages/FANotesPage.swift#L37 with individual item parsing just after, line 47
• parallelMap is defined in https://github.com/Ceylo/FurAffinityApp/blob/main/FAKit/Sources/FAPages/Collection%2Bparallel.swift

All in all I wouldn't say that the app would be broken without parallelism, but I'd lose up to 90ms on a view display, for a page complete data loading that can currently be as low as 200ms, including network latency.

[aehlke]

Can you share your select() param - maybe it's something that can be optimized

If it's just selecting a tag or class name, those are optimized if you use the tag or class name specific methods. It just occurred to me that we should check for simple select() queries such as ".foo" and use the optimized call...

Edit: checked your code briefly. Maybe you can simply select on the very last class name, using the optimized method, depending on the html

Another route would be to contribute optimization for select queries to use the class and tag name caches I added for the respective specialized methods. That would be great to have and very flexible

[Ceylo]

Do you mean selecting on .note-list-container instead of div#main-window div#site-content div.messagecenter-mail-container div.messagecenter-mail-content-pane div.messagecenter-mail-list form#pms-form div.messagecenter-mail-list-pane div#notes-list div.c-noteListItem div.note-list-container for instance?

If so, then it's a bit risky on my end: I don't own the target website so the HTML structure may change and the owner may decide to use the note-list-container class in an unexpected place.

As for contributing, this is also an option although not on short term as I don't have enough time at the moment.

[aehlke]

It should be very fast if it uses getElementsByClass which uses indexes and would probably not need to be parallelized anymore. Though it also adds some extra compute to build the index (happens automatically and lazily) so there's a balance.

The potential contribution from you or someone else would be to reuse that index and the tag name index inside .select() queries

Without that you may also try switching to getElementsByClass and then adding a check that they belong to appropriate parents. This might be faster than using select()

[DarkDust]

I did a few test with @Ceylo 's app and I found a few things to speed up the processing considerably. Had to create two accounts to send messages to each other for this. ^_^ I want to suggest a few minor SwiftSoup API changes to make this nicer.

My changes:

• Use doc.getElementById(_:) to quickly get the main container.
• Use cached Evaluator instances to have the .select(…) calls avoid parsing the queries every time.

Times (debug build, iOS simulator on my MacBook Pro, the part directly after HTML parsing until the end of the initializer):

• 1 Message:
  • Original: ~0.0075s
  • My changes, with parallelMap: ~0.0020s
  • My changes, with sequential map (thus no async): ~0.0015s
• 5 Messages:
  • Original: ~0.0085s
  • My changes, with parallelMap: ~0.0030s
  • My changes, with sequential map (thus no async): ~0.0050s

So granted, the parallel version is still faster with multiple messages (which is expected), but even my sequential version is faster than the original parallel version.

I had a hard time looking at this in Instruments: in the release build it's so fast it just just doesn't show up on my system. I had to run the debug build in Instruments to see it, and even the by far the biggest part was parsing the HTML.

---

The main change to speed things is up is avoid parsing the select queries every time. I've used a simple helper:

private func createEvaluator(_ query: String) -> Evaluator {
    do {
        return try QueryParser.parse(query)
    } catch {
        fatalError("Cannot evaluate query")
    }
}

Next, I've created static properties like this:

private static let baseEval = createEvaluator("div.note-list-subjectgroup div.note-list-subject-container a.notelink")
private static let inputEval = createEvaluator("div.note-list-subjectgroup div.note-list-checkbox input")
…

The queries then look like this:

let baseNode = try CssSelector.select(Self.baseEval, node)
…
let idStr = try CssSelector.select(Self.inputEval, node).attr("value")
…

That's main part of the speedup. Another improvement is to use .getElementById to get the main parent node of the message list, which limits the amount of nodes that need iteration using select:

private static let notesEval: Evaluator = createEvaluator("div.c-noteListItem div.note-list-container")

…

guard let notesList = try doc.getElementById("notes-list") else {
    return nil
}

let noteNodes = try CssSelector.select(Self.notesEval, notesList)
self.noteHeaders = try noteNodes.map { try NoteHeader($0) }

---

Here's some changes to SwiftSoup I'd like to propose:

• There's currently func select(_ cssQuery: String) throws -> Elements on Element and Elements which just wrap CssSelector.select(_:_:).
• I'd like to introduce variants func select(_ eval: Evaluator) throws -> Elements on Element and Elements that do the same.
  • While it's easy to replace element.select("query") with CssSelector.select(evaluator, element), it's not easily "discoverable".
  • The Elements (plural) version requires additional work that currently private. If we introduce public Elements.select(_ eval: Evaluator) we don't need to expose the currently private part.
• I also want to mark the Evaluator class and subclasses @unchecked Sendable: they're all immutable.

I'm going to submit a SwiftSoup PR soon, and maybe another one for FurAffinityApp. ^_^

[aehlke]

Looks great!

Btw in instruments there is an option to do high resolution profiling that sometimes fixes that issue

[Ceylo]

Wow, thanks for the investigation!

Indeed in Instruments you need to select the option to record the last 10s or so. If you use the immediate mode you'll miss signposts.

[Ceylo]

Hello,
I finally had time to test the latest SwiftSoup version and do some profiling. Based on the results in Ceylo/FurAffinityApp#18 (comment) I'd be fine with dropping concurrency, as I get about the same speed with 2.11 in most cases, without having to run concurrently.

I just want to point out a 36% speed regression on SwiftSoup.parse() between 2.7.5 and 2.11, which looks to involve a new HtmlTreeBuilder. I'll try to come up with a small sample code.

[Ceylo]

Here is a sample project to reproduce the issue. I also give traces from my M1 Pro and A15 (iPhone 13 Pro).

M1 Pro with SwiftSoup 2.7.5:

A15 with SwiftSoup 2.7.5:

M1 Pro with SwiftSoup 2.11:

A15 with SwiftSoup 2.11:

I also notice that the first iteration is significantly longer than the following iterations with 2.11, while it doesn't change as much with 2.7.5. It could be that in my use case I'm only seeing the first iteration and fall in the worst case.

SwfitSoup.parse iOS.trace.zip
SwfitSoup.parse macOS.trace.zip
SwiftSoup.parse-app.zip

[DarkDust]

Thank you very much for your effort! I've created a new task #346 for the speed regression. I hope to be able to work on this in a couple of days.