[SR-12928] `.first` is less efficient than `.first { _ in true }` on LazyMapSequence #55374

swift-ci · 2020-06-02T21:41:01Z


Previous ID	SR-12928
Radar	None
Original Reporter	bubski (JIRA User)
Type	Bug

Attachment: Download

Environment

Apple Swift version 5.2.2 (swiftlang-1103.0.32.6 clang-1103.0.32.51)
Target: x86_64-apple-darwin19.4.0

macOS 10.15.4 (19E287)

Xcode 11.4.1

Additional Detail from JIRA


Votes	0
Component/s	Standard Library
Labels	Bug
Assignee	None
Priority	Medium

md5: 38b32ecf66be259b2052152057060ea8

Issue Description:

_ = (1...1)
    .lazy
    .compactMap { value -> String? in
        print("lazy compactMap a \(value)")
        return "\(value)"
}.first

_ = (1...1)
    .lazy
    .compactMap { value -> String? in
        print("lazy compactMap b \(value)")
        return "\(value)"
}.first { _ in true }

_ = (1...1)
    .compactMap { value -> String? in
        print("eager compactMap \(value)")
        return "\(value)"
}.first

// output:
// lazy compactMap a 1
// lazy compactMap a 1
// lazy compactMap b 1
// eager compactMap 1

Shouldn't .first be synonymous to .first { _ in true } in terms of not only result, but also effort?

Also, is lazy

_ = (1...1)
    .lazy
    .compactMap { value -> String? in
        print("lazy compactMap a \(value)")
        return "\(value)"
}.first

being less efficient than eager

_ = (1...1)
    .compactMap { value -> String? in
        print("eager compactMap \(value)")
        return "\(value)"
}.first

expected?

swift-ci · 2021-05-28T14:00:13Z

Comment by Jarek Pendowski (JIRA)

Any updates on that? I know - pandemic and all that - but that's quite serious. Why is it evaluating `compactMap` twice?

See apple/swift#55374 `.first` has been broken since 2020.

NachoSoto · 2023-11-21T23:49:00Z

This is still an issue on Swift 5.9

See apple/swift#55374 `.first` has been broken since 2020.

oscbyspro · 2024-02-18T08:16:44Z

I looked into this and thought I'd share some insights. The lazy.compactMap({ $0 }).first expression invokes its closure twice as a result of how Collection/first, LazyFilterSequence/startIndex, and LazyMapSequence/subscript(_:) work:

swift/stdlib/public/core/FlatMap.swift

Lines 41 to 51 in 23a0186

    
             @inlinable // lazy-performance 
        
             public func compactMap<ElementOfResult>( 
        
               _ transform: @escaping (Elements.Element) -> ElementOfResult? 
        
             ) -> LazyMapSequence< 
        
               LazyFilterSequence< 
        
                 LazyMapSequence<Elements, ElementOfResult?>>, 
        
               ElementOfResult 
        
             > { 
        
               return self.map(transform).filter { $0 != nil }.map { $0! } 
        
             } 
        
           }

swift/stdlib/public/core/Collection.swift

Lines 1100 to 1105 in 30984f5

    
           @inlinable 
        
           public var first: Element? { 
        
             let start = startIndex 
        
             if start != endIndex { return self[start] } 
        
             else { return nil } 
        
           }

swift/stdlib/public/core/Filter.swift

Lines 140 to 147 in 30984f5

    
           @inlinable // lazy-performance 
        
           public var startIndex: Index { 
        
             var index = _base.startIndex 
        
             while index != _base.endIndex && !_predicate(_base[index]) { 
        
               _base.formIndex(after: &index) 
        
             } 
        
             return index 
        
           }

swift/stdlib/public/core/Map.swift

Lines 120 to 123 in 30984f5

    
           @inlinable 
        
           public subscript(position: Base.Index) -> Element { 
        
             return _transform(_base[position]) 
        
           }

As you can see, LazyFilterSequence invokes the closure while finding the startIndex, and LazyMapSequence invokes the closure again when the startIndex subscripts the collection. It is a bit silly. first { _ in true }, on the other hand, returns the first iterator element that passes through the filter.

swift-ci transferred this issue from apple/swift-issues Apr 25, 2022

NachoSoto added a commit to RevenueCat/purchases-ios that referenced this issue Nov 20, 2023

Optimization: changed first to first(where:)

28f6d7f

See apple/swift#55374 `.first` has been broken since 2020.

NachoSoto mentioned this issue Nov 21, 2023

Optimization: changed first to first(where:) RevenueCat/purchases-ios#3467

Merged

NachoSoto added a commit to RevenueCat/purchases-ios that referenced this issue Dec 6, 2023

Optimization: changed first to first(where:) (#3467)

56daf52

See apple/swift#55374 `.first` has been broken since 2020.

oscbyspro mentioned this issue Feb 18, 2024

Lazier first element #71714

Open

Kudo mentioned this issue Mar 13, 2024

[core][dev-client][updates] add bridgeless support for ExpoReactDelegate expo/expo#27601

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SR-12928] `.first` is less efficient than `.first { _ in true }` on LazyMapSequence #55374

[SR-12928] `.first` is less efficient than `.first { _ in true }` on LazyMapSequence #55374

swift-ci commented Jun 2, 2020

swift-ci commented May 28, 2021

NachoSoto commented Nov 21, 2023

oscbyspro commented Feb 18, 2024 •

edited

[SR-12928] .first is less efficient than .first { _ in true } on LazyMapSequence #55374

[SR-12928] .first is less efficient than .first { _ in true } on LazyMapSequence #55374

Comments

swift-ci commented Jun 2, 2020

swift-ci commented May 28, 2021

NachoSoto commented Nov 21, 2023

oscbyspro commented Feb 18, 2024 • edited

[SR-12928] `.first` is less efficient than `.first { _ in true }` on LazyMapSequence #55374

[SR-12928] `.first` is less efficient than `.first { _ in true }` on LazyMapSequence #55374

oscbyspro commented Feb 18, 2024 •

edited