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 sampling interval is hardcoded to 4.5ms here: https://github.com/EmergeTools/ETTrace/blob/15b5ae7de8408a7f4d9181ce422eb168420c9fc4/ETTrace/ETTrace/EMGPerfAnalysis.mm#L80
When building the flamechart the time between traces is also capped at 5ms: https://github.com/EmergeTools/ETTrace/blob/15b5ae7de8408a7f4d9181ce422eb168420c9fc4/ETTrace/ETTraceRunner/Utils/FlamegraphGenerator.swift#L15
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.