Thread by @Zimareff

I might be missing something but why people from Microsoft write code like this? github.com/open-telemetry…

So I changed the method of 36 lines with 4 ifs and two nested fors with this:
this.entries = carrier is NoopDistributedContextCarrier || entries == null
? Enumerable.Empty<DistributedContextEntry>()
: entries.Where(x => x != default).Distinct();

I wrote a test that profiles two methods on the same dataset of 10 instances of DistrobitedContext, where each gets 1000 entries.

With LINQ:(1576613193606, 1576613193608, 00:00:00.0020000)
With bloody fors: (1576613193610, 1576613201547, 00:00:07.9370000)

Not only their code is cumbersome and hard to follow, but it's also horribly slow.

You might say it's not that important, but it's tracing. We produce thousands of traces per seconds and some companies produce millions.

But the worst part is that they accept IEnumerable and enumerate it SIX times in that method. My IDE screams with warnings.

So I created a small function that returns IEnumerable<DistributedContextEntry> with one millisecond delay between entries.

To add insult to injury, five of those enumerations occur within a for loop running over... the same bloody enumerable!

And the final bit - inside that for loop, there's another for loop. You may guess now. Yes, it runs over the same enumerable.

And inside the first loop, the first line calls ElementAt(x) of... The enumerable! Guess what it does to get the Nth element... I am still waiting for the test to finish.

So, with 1000 elements in the enumeration that has one ms delay in yield, I gave up waiting. Ended up with 30 elements, so I get reasonable results

With LINQ: (1576618954702, 1576618954703, 00:00:00.0010000)
With repeated enumerations: (1576618954705, 1576618967804, 00:00:13.0990000)

The difference is... Well, it's infinite. What strikes me too is that they have tons of analysers like the XML comment on a property must end with a dot.

But this obvious repeated enumeration of IEnumerable - no, seems like it's not an issue at all, compared to that. Bravo, #Microsoft. The best example for .NET devs to learn how NOT to write C# code. Never, ever.

The most confusing thing though is that if you look at BinaryFormatter, it looks really decent. Using Span<byte> and slices, seems like people spend time thinking of performance. So, why other pieces are so different, so bad?

Adjacent to the binary formatter you'd find the TraceContextFormat that first does collection.Count() != 1 and then collection.First(). Yes, the collection is IEnumerable again. Why? Why???

And this? github.com/open-telemetry… Service locator when using a DI container, your own container???

Ok, enough for now. I mean, OpenTelemetry is important. I write before that we are now in a limbo between OpenTracing being abandoned and OpenTelemetry not being ready. In reality, we need it. We need traces, metrics and all that.

But we need libraries that support all that to be fast and reliable. Not like opentelemetry-dotnet. If Microsoft wants it to be fixed, let's see how PRs would go. If not - the community needs to build another lib.