You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In practice this seems to work well, and lower values can cause the thread to not be scheduled in time leading to more unattributable time between traces. However, we should make it use-configurable. This might involve including the sample interval used in the data sent over PeerTalk so it can be used when constructing the flamechart. Since recording at app launch might start automatically based on the Info.plist flag I don't think the value can be an argument in the CLI, it might need to be a plist property provided to the iOS framework. Unless we add the property to the framework and an override in the CLI arguments that won't take affect if the sampling was already started.
The text was updated successfully, but these errors were encountered:
The sampling interval is hardcoded to 4.5ms here:
ETTrace/ETTrace/ETTrace/EMGPerfAnalysis.mm
Line 80 in 15b5ae7
When building the flamechart the time between traces is also capped at 5ms:
ETTrace/ETTrace/ETTraceRunner/Utils/FlamegraphGenerator.swift
Line 15 in 15b5ae7
In practice this seems to work well, and lower values can cause the thread to not be scheduled in time leading to more unattributable time between traces. However, we should make it use-configurable. This might involve including the sample interval used in the data sent over PeerTalk so it can be used when constructing the flamechart. Since recording at app launch might start automatically based on the Info.plist flag I don't think the value can be an argument in the CLI, it might need to be a plist property provided to the iOS framework. Unless we add the property to the framework and an override in the CLI arguments that won't take affect if the sampling was already started.
The text was updated successfully, but these errors were encountered: