Cutting the SignalProducer overhead further. #487

andersio · 2017-07-17T07:15:06Z

Goals

Taking advantage of the deferred nature of SignalProducer to further reduce the overhead.

TL;DR

Composing SignalProducer is going to be way, way cheaper than composing Signal.
Constant SignalProducers, e.g. init(value:) and sequence init(_:), are going to do significantly less work.
There is still a ~16x overhead over standard library lazy for purely collection manipulation. But given the type erasing and reactive (passive) nature of FRP/ReactiveSwift, there is probably very little stuff we can do about it. IOW optimizing for this is a non-goal. :)

The actual speedup is subject to the new internal API adoption — unmigrated SignalProducer operators would still be relying on the conventional behavior and/or lift.

For example, if you do:

SignalProducer(Array(repeating: 1, count: 1000)).skipRepeats()

The performance remains the same as master, because skipRepeats hasn't been migrated yet.

Introducing `SignalProducerCore`

SignalProducerCore is the new internal abstraction of SignalProducer. It has subsumed three major responsibilities from SignalProducer:

~~the actual implementation of startWithSignal;~~
the actual implementation of start which accepts an Signal.Observer; and
the builder closure, now as Core.make(), which produces a Signal and the relevant context for composition and startWithSignal.

SignalProducerCore provides default implementations of all these capabilities for its subclasses, except for Core.make().

The cores are not nested in SignalProducer because the Swift 3.1 compiler would get stuck. The Swift 4 compiler has resolved the issue though.

`SignalProducerCore` subclasses

`SignalCore`

This is the conventional SignalProducer with the Signal operator lifting optimisation in ReactiveSwift 2.0 (#140).

`EventTransformingCore`

EventTransformingCore composes event transforms, and is exposed as a new operator Core.flatMapEvent (internal for now).

It takes advantage of the deferred, single-observer nature of SignalProducer. For example, when we do:

upstream.map(transform).filterMap(filteringTransform).start()

It is contractually guaranteed that these operators would always end up producing a chain of streams, each with a single and persistent observer to its upstream. The multicasting & detaching capabilities of Signal is useless in these scenarios.

So EventTransformingCore builds on top of this very fact, and composes directly at the level of event transforms. This change implicitly nullifies #129, since producers no longer use Signal unless it absolutely has to.

It is intended for all synchronous SignalProducer operators. To encourage code reusing, the pilot operators have their implementation moved under Signal.Event, and Signal has gained flatMapEvent to use these Event-level operator implementations.

This represents a new type of SignalProducer that does not use Signal unless it is requested via make().

Example

extension Signal {
	public func filterMap<U>(_ transform: @escaping (Value) -> U?) -> Signal<U, Error> {
		return flatMapEvent(Signal.Event. filterMap(transform))
	}
}

extension SignalProducer {
	public func filterMap<U>(_ transform: @escaping (Value) -> U?) -> SignalProducer<U, Error> {
		return core.flatMapEvent(Signal.Event. filterMap(transform))
	}
}

`EventGeneratingCore`

EventGeneratingCore wraps a generator closure that would be invoked when started. All the generator closure have are the observer and the cancel disposable.

It is intended for the constant SignalProducers, as in #486, which synchronously emits all events.

It represents a new type of SignalProducer that does not use Signal unless it is requested via make().

Pilot public APIs

map, mapError, filter and filterMap.
Various SignalProducer.init overloads that accept a constant.

Results

Test	Sequence (32 items)	Value	SequenceMapFilter
`master`	avg 30296 ns min 26426 ns	avg 8910 ns min 8171 ns	avg 61555 ns min 50378 ns
This PR	avg 14073 ns min 13079 ns	avg 839 ns min 739 ns	avg 8304 ns min 7198 ns
Speedup	~2.15x	~10.5x	~7.5x
`master` WMO	avg 29333 ns min 26136 ns	avg 8613 ns min 7169 ns	31340 ns min 27497 ns
This PR WMO	avg 13591 ns min 11382 ns	avg 388 ns min 325 ns	avg 5923 ns min 5002 ns
Speedup WMO	~2.15x	~22.00x	~5.29x

Benchmark Source

Checklist

Updated CHANGELOG.md.

andersio · 2017-07-17T08:37:51Z

Heh, the compiler gets stuck.

mdiep · 2017-07-18T12:45:59Z

Sources/Signal.swift

-			return self.observe { event in
-				observer.action(event.map(transform))
-			}
+	public func flatMapEvent<U, E>(_ transform: @escaping (@escaping Signal<U, E>.Observer.Action) -> (Event) -> Void) -> Signal<U, E> {


Not sure if this should be public, but the documentation is definitely wrong.

mdiep · 2017-07-18T13:05:47Z

Sources/SignalProducer.swift

+	}
+}
+
+internal class SignalProducerCore<Value, Error: Swift.Error> {


Can we make this a protocol instead of a class? I have an aversion to inheritance.

Since we don't have generalised existential for now, we would need a type-erased wrapper if we use protocol.

In the end, it would be similar to what SignalProducerCore is doing here.

Instead of inheritance, it can also be implemented with an enum backing (what Foundation Data uses).

https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/Data.swift

I think an enum backing would be preferable. 👍

Hmm, I just realised that EventTransformingCore relies on the inheritance to erase generic parameters. So unless we ditch EventTransformingCore, an enum backing cannot sufficiently represent all these. 🤔

mdiep · 2017-08-09T12:17:34Z

Sources/SignalProducer.swift

-	}
-
-	fileprivate let builder: () -> Instance
+	fileprivate let core: SignalProducerCore<Value, Error>


Can you add some documentation for this?

mdiep · 2017-08-09T12:19:27Z

Sources/SignalProducer.swift

+	}
+}
+
+internal class SignalProducerCore<Value, Error: Swift.Error> {


I think an enum backing would be preferable. 👍

mdiep · 2017-08-09T12:24:08Z

Sources/SignalProducer.swift

+	/// the upstreams for producer interruption.
+	///
+	/// `observerDidSetup` must be invoked before any other post-creation side effect.
+	struct Product {


I really dislike the name Product here. Could we come up with something more specific?

mdiep · 2017-08-09T12:24:24Z

Sources/SignalProducer.swift

+	/// customized `observerDidSetup` post-creation side effect for the `Signal` and a
+	/// disposable to interrupt the produced `Signal`.
+	///
+	/// Unlike the safe `startWithSignal(_:)` API, `builder` shifts the responsibility of


builder here needs to be updated

mdiep · 2017-08-14T13:21:57Z

Sources/Disposable.swift

+	var isDisposed = false
+	func dispose() {}
+	private init() {}
+}


This breaks the contract of Disposable by not changing isDisposed when you call dispose. It may be fine in practice, but this makes me very wary.

I think we'd be better off bringing back the implementation of SimpleDisposable and using that instead.

Can we treat it as disposed then? It still makes sense for its use case.

Why not bring back SimpleDisposable? This still strikes me as a little weird.

This is a shared disposable for constant producers that practically would never be disposed of, because they terminate before the disposable is returned.

When I iterate on the design, benchmark shows allocation contributes considerable overhead over NopDisposable.shared (which uses swift_once). I could check again to see if the numbers are still high though.

mdiep · 2017-08-14T13:24:16Z

Sources/SignalProducer.swift

+	/// It is the responsibility of the `ProducedSignalReceipt` consumer to ensure the
+	/// starting side effect is invoked exactly once, and is invoked after observations
+	/// has properly setup.
+	struct ProducedSignalReceipt {


How about calling this Instance?

mdiep · 2017-08-14T13:26:25Z

Sources/SignalProducer.swift

+				let right = otherProducer.core.make()
+
+				return .init(signal: transform(left.signal)(right.signal),
+				             observerDidSetup: {


Could we put all the arguments on their own line? 🙈

return .init( signal: transform(left.signal), observerDidSetup: { ... }, ... )

It's minor, but I think it has readability benefits. (Including outdenting the block body.)

mdiep · 2017-08-14T13:27:01Z

Sources/Observer.swift

@@ -18,6 +18,24 @@ extension Signal {
 		/// Whether the observer should send an `interrupted` event as it deinitializes.
 		private let interruptsOnDeinit: Bool

+		/// The target observer of `self`.
+		private let wrapped: AnyObject?


I don't love adding more to Observer. 😕

Sadly, we have to retain observers marked with interruptsOnDeinit, and retaining it using a thunk adds an overhead to all calls to the observer, as opposed to an 8 byte storage for a reference. :|

// @testEventTransformingCoreMapFilter(): avg 6091 ns; min 5250 ns self.action = transform(observer.action) self.wrapped = observer // @testEventTransformingCoreMapFilter(): avg 6238 ns; min 5402 ns self.action = transform { observer.action($0) }

mdiep · 2017-08-14T13:28:06Z

Sources/SignalProducer.swift

@@ -77,23 +63,24 @@ public struct SignalProducer<Value, Error: Swift.Error> {
 	/// - parameters:
 	///   - startHandler: A closure that accepts observer and a disposable.
 	public init(_ startHandler: @escaping (Signal<Value, Error>.Observer, Lifetime) -> Void) {
-		self.init { () -> Instance in
+		core = SignalCore {


It's small, but the other inits case self.init(<core instance>).

Can we update this one or the others to make them consistent?

mdiep · 2017-08-14T13:29:56Z

Sources/SignalProducer.swift

+		let interruptHandle: Disposable
+	}
+
+	func make() -> ProducedSignalReceipt {


I think this should be makeInstance() (or whatever we call the struct).

mdiep · 2017-08-14T13:31:30Z

Sources/SignalProducer.swift

+///
+/// It is intended for constant `SignalProducers`s that synchronously emits all events
+/// without escaping the `Observer`.
+private final class EventGeneratingCore<Value, Error: Swift.Error>: SignalProducerCore<Value, Error> {


We could probably just call this GeneratorCore

mdiep · 2017-08-14T13:32:18Z

Sources/SignalProducer.swift

+/// level of event transforms, without any `Signal` in between.
+///
+/// - note: This core does not use Signal unless it is requested via `make()`.
+private final class EventTransformingCore<Value, Error: Swift.Error, SourceValue, SourceError: Swift.Error>: SignalProducerCore<Value, Error> {


We could probably call this TransformerCore or FlatMapCore.

mdiep · 2017-08-14T13:33:04Z

This is looking good overall. 👍 👍

andersio · 2017-08-15T04:37:13Z

@mdiep

For SignalProducer(value:), the allocation of a non-atomic SimpleDisposable contributes a ~30% overhead w/ WMO.

@testValue(): avg 546 ns; min 475 ns
@testValue(): avg 388 ns; min 325 ns

internal final class _SimpleDisposable: Disposable {
	var isDisposed = false

	func dispose() {
		isDisposed = true
	}
}

…tomicState.is`.

andersio · 2017-08-15T05:22:34Z

The cost of sequence backed producers is slightly up with the implementation being corrected in 56131fc, but the difference is trivial given its scale.

The comparison in UnsafeAtomicState.is has been relaxed too to help with the sequence backed producers. The barrier is redundant with tryTransition already issuing one. The CAS is redundant because the read is already atomic on all supported platforms.

All other constant producers still use NopDisposable.

@testEventTransformingCoreMapFilter(): avg 6091 ns; min 5250 ns
@testSequence(): avg 13277 ns; min 11720 ns
@testValue(): avg 369 ns; min 317 ns

mdiep · 2017-08-17T13:19:07Z

Sources/SignalProducer.swift

-		let instance = builder()
-		setup(instance.producedSignal, instance.interruptHandle)
-		guard !instance.interruptHandle.isDisposed else { return }
+		let receipt = core.makeInstance()


receipt should be instance here

mdiep · 2017-08-20T18:32:27Z

CHANGELOG.md

 # 2.0.1
 1. Addressed the exceptionally high build time. (#495)

 1. New method ``retry(upTo:interval:on:)``. This delays retrying on failure by `interval` until hitting the `upTo` limitation.

+1. Addressed the exceptionally high build time. (#495)


This line is duplicated in the 2.0.1 notes. 🙈

mdiep · 2017-08-21T17:34:54Z

🎉

andersio force-pushed the event-transforming branch from 043c47f to 104f5af Compare July 17, 2017 08:10

andersio added this to the 2.1+ milestone Jul 17, 2017

andersio force-pushed the event-transforming branch from ea452ff to c9f93e8 Compare July 17, 2017 10:26

EventTransformingCore

5cb7499

andersio force-pushed the event-transforming branch 2 times, most recently from e0d9c49 to b0e1020 Compare July 18, 2017 06:01

mdiep reviewed Jul 18, 2017

View reviewed changes

andersio force-pushed the event-transforming branch from d1459d9 to 58c87a0 Compare July 18, 2017 15:15

andersio added 4 commits July 19, 2017 14:36

EventGeneratingCore.

bbd8da3

flatMapEvent.

997dd2e

Unnested the producer cores to unstick the compiler.

0eaa0e2

Made Signal.flatMapEvent internal. Added docs.

c5ab301

andersio force-pushed the event-transforming branch from 58c87a0 to c5ab301 Compare July 19, 2017 06:36

mdiep requested changes Aug 9, 2017

View reviewed changes

andersio added 4 commits August 10, 2017 00:00

Improve docs. Move startWithSignal out of the cores.

8474282

Merge branch 'master' into event-transforming

58086db

Update the changelog.

5ce3c5a

Merge branch 'master' into event-transforming

ce3fe65

andersio force-pushed the event-transforming branch from d0c2e2e to ce3fe65 Compare August 11, 2017 07:38

mdiep requested changes Aug 14, 2017

View reviewed changes

andersio added 2 commits August 15, 2017 13:22

Fixed the use of disposables in EventGeneratingCore. Relaxed `UnsafeA…

950d2a3

…tomicState.is`.

Rename the producer cores. Code formatting improvements.

4bc0c81

andersio force-pushed the event-transforming branch from 798cc2d to 4bc0c81 Compare August 15, 2017 05:22

mdiep requested changes Aug 17, 2017

View reviewed changes

andersio added 2 commits August 19, 2017 10:54

Merge remote-tracking branch 'origin/master' into event-transforming

54bf88f

Rename receipt to instance.

b6bbb8a

mdiep requested changes Aug 20, 2017

View reviewed changes

Remove a redundant line in the CHANGELOG. [skip ci]

748b4c0

mdiep approved these changes Aug 21, 2017

View reviewed changes

mdiep merged commit ea5fd45 into master Aug 21, 2017

mdiep deleted the event-transforming branch August 21, 2017 17:34

andersio mentioned this pull request Aug 26, 2017

Improve TransformerCore and move take(first:). #505

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cutting the SignalProducer overhead further. #487

Cutting the SignalProducer overhead further. #487

andersio commented Jul 17, 2017 •

edited

Loading

andersio commented Jul 17, 2017

mdiep Jul 18, 2017

mdiep Jul 18, 2017

andersio Jul 18, 2017 •

edited

Loading

andersio Aug 5, 2017

mdiep Aug 9, 2017

andersio Aug 9, 2017 •

edited

Loading

mdiep Aug 9, 2017

mdiep Aug 9, 2017

mdiep Aug 9, 2017

mdiep Aug 9, 2017

mdiep Aug 14, 2017

andersio Aug 14, 2017 •

edited

Loading

mdiep Aug 14, 2017

andersio Aug 14, 2017 •

edited

Loading

mdiep Aug 14, 2017

mdiep Aug 14, 2017

mdiep Aug 14, 2017

andersio Aug 15, 2017 •

edited

Loading

mdiep Aug 14, 2017

mdiep Aug 14, 2017

mdiep Aug 14, 2017

mdiep Aug 14, 2017

mdiep commented Aug 14, 2017

andersio commented Aug 15, 2017 •

edited

Loading

andersio commented Aug 15, 2017 •

edited

Loading

mdiep Aug 17, 2017

mdiep Aug 20, 2017

mdiep commented Aug 21, 2017

Cutting the SignalProducer overhead further. #487

Cutting the SignalProducer overhead further. #487

Conversation

andersio commented Jul 17, 2017 • edited Loading

Goals

TL;DR

Introducing SignalProducerCore

SignalProducerCore subclasses

SignalCore

EventTransformingCore

Example

EventGeneratingCore

Pilot public APIs

Results

Checklist

andersio commented Jul 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Jul 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Aug 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Aug 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Aug 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Aug 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdiep commented Aug 14, 2017

andersio commented Aug 15, 2017 • edited Loading

andersio commented Aug 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdiep commented Aug 21, 2017

andersio commented Jul 17, 2017 •

edited

Loading

Introducing `SignalProducerCore`

`SignalProducerCore` subclasses

`SignalCore`

`EventTransformingCore`

`EventGeneratingCore`

andersio Jul 18, 2017 •

edited

Loading

andersio Aug 9, 2017 •

edited

Loading

andersio Aug 14, 2017 •

edited

Loading

andersio Aug 14, 2017 •

edited

Loading

andersio Aug 15, 2017 •

edited

Loading

andersio commented Aug 15, 2017 •

edited

Loading

andersio commented Aug 15, 2017 •

edited

Loading