After we integrated Snowplow in our product we did some performance testing to determine the performance impact of the Snowplow library.
We determined that the Tracker.track method was responsible for 3.2% of overhead during our most common use case (this was determined using). This overhead is synchronous and thus is noticeable by the users of our product.
This overhead was mostly caused by adding the data to the TrackerPayload. To create a better user experience, we tried moving the logic on the TrackerPayload from the Tracker to the Emitter, which in our case is the BatchEmitter and has its own ThreadPool.
The result of this that the synchronous overhead was reduced to 0.2%. The overhead of the operations was mvoed to the ThreadPool of the Emitter.
These changes can be found at asyncTrack branch
These changes also add a constructor for the Subject class, which enables a subject object to be reused.
After we integrated Snowplow in our product we did some performance testing to determine the performance impact of the Snowplow library.
We determined that the Tracker.track method was responsible for 3.2% of overhead during our most common use case (this was determined using). This overhead is synchronous and thus is noticeable by the users of our product.
This overhead was mostly caused by adding the data to the TrackerPayload. To create a better user experience, we tried moving the logic on the TrackerPayload from the Tracker to the Emitter, which in our case is the BatchEmitter and has its own ThreadPool.
The result of this that the synchronous overhead was reduced to 0.2%. The overhead of the operations was mvoed to the ThreadPool of the Emitter.
These changes can be found at asyncTrack branch
These changes also add a constructor for the Subject class, which enables a subject object to be reused.