================
@@ -73,9 +100,50 @@ class TelemetryManager : public llvm::telemetry::Manager {
private:
std::unique_ptr<llvm::telemetry::Config> m_config;
+ // Each instance of a TelemetryManager is assigned a unique ID.
+ const std::string m_id;
----------------
oontvoo wrote:
> One reason for storing it in the UUID form might be if we think that someone
> could be interested in storing/transmitting the UUID in a binary form
This is the TelemetryManager - it is never transmitted or serialised anywhere.
So why does compactness matter?
If you mean storing the id as UUID in the `TelemetryInfo` object, then we'd
need to update the llvm base interface. However, the reason the id was a string
in the base interface was because people wanted flexibility in what the id
could be in each implementation.
Also the downside of storing it as UUID object is that you may have different
`telemetry::Serializer` objects generating different values for the same UUID
(ie.,different separators?). That's potentially problematic because ultimately,
the point of this field is for grouping entries from the same session. We need
the key to be identical across entries and not "accidentally" differ because
of serialisation methods.
https://github.com/llvm/llvm-project/pull/127696
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
