Please help me understand profile hotspot

Jesse_Grosjean · 2022-07-14T22:57:41.560Z

I have this method that's slower then I would have expected.

public func isMatch<E>(_ element: E) -> Bool where E: Element {
   ...
}

And here is the profile:

hotspot1416×534 141 KB

What is the initializeWithCopy for RunElement and destroy for RunElement code doing. Can I avoid it?

In this case RunElement is a struct conforming to Element. Is this because I'm using a struct? Would it be faster using a reference type?

Also what about swift_bridgeObjectRetain and release? I understand that swift needs to do retain count logic... but the "bridgeObject" label makes me wonder... does that mean this code is bridging to object-c? I expect this code to be all swift native, but maybe there's some bridging to object-c that I need to search for.

Thanks,
Jesse

Jon_Shier · 2022-07-14T23:30:56.041Z

Where is this isMatch from? AFAICT Selector doesn't declare this. Are you matching an element in a collection? From what I can see this isMatch is calling through to Selector, which calls into the Obj-C runtime, unless you have a bunch of shadowed types here. We really need more context here.

Jesse_Grosjean · 2022-07-14T23:49:36.484Z

Sorry for the confusion... Selector is my own type. I've just posted in progress code here:

github.com

jessegrosjean/StyleLib/blob/main/Sources/StyleLib/Selector.swift

public struct Selector {
    
    public let matches: [Match]
    public let specificity: Specificity
    
    public init(matches: [Match] = [], specificity: Specificity = Specificity()) {
        self.matches = matches
        self.specificity = specificity
    }

    public func isMatch<E>(_ element: E) -> Bool where E: Element {
        guard matches.count > 0 else {
            return false
        }
        return isMatch(element, index: matches.count - 1)
    }

    private func isMatch<E>(_ element: E, index: Int) -> Bool where E: Element {
        var index = index
        while index >= 0 {

This file has been truncated. show original

StyleLib is a package. The struct that I'm passing in is from another package:

import StyleLib

struct RunElement {
    let parent: ItemElement
    let run: AttributedText.Run
}

extension RunElement: Element {
...

Jon_Shier · 2022-07-15T00:06:00.361Z

Yes, I think your recursive algorithm is creating copies of the values it passes down but I'm not really sure. Someone who knows should take a look.

Jesse_Grosjean · 2022-07-15T00:11:43.314Z

Thanks for taking a look. I guess I will try using a class type instead and see if that makes a difference.

Also for anyone else looking at the profile, while the algorithm is recursive... in that profile there's no recursion happening... there are no .child or .descendant matches.

Jesse_Grosjean · 2022-07-15T01:03:25.884Z

I think this is solved. Root of problem seems to be that the structs passed around were too large. This helped:

github.com

apple/swift/blob/main/docs/OptimizationTips.rst#the-cost-of-large-swift-values

===================================
Writing High-Performance Swift Code
===================================

.. contents:: :local:

The following document is a gathering of various tips and tricks for writing
high-performance Swift code. The intended audience of this document is compiler
and standard library developers.

Some of the tips in this document can help improve the quality of your Swift
program and make your code less error prone and more readable. Explicitly
marking final-classes and class-protocols are two obvious examples. However some
of the tips described in this document are unprincipled, twisted and come to
solve a specific temporary limitation of the compiler or the language. Many of
the recommendations in this document come with trade offs for things like
program runtime, binary size, code readability, etc.


Enabling Optimizations

This file has been truncated. show original