Please help me understand profile hotspot

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:

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

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.

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

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 {
...

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.

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.

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