-
Notifications
You must be signed in to change notification settings - Fork 930
Description
By doing some profiling, I discovered that the introduction of AsyncLocal<> inside the SessionIdLoggingContext caused a performance regression of approximately 6.5% when retrieving a bigger result set.
Here is the test that I ran, which uses the data provided by the LinqTestCase class.
[Test]
public void PerformanceTest()
{
var list =
db.Orders
.FetchMany(o => o.OrderLines)
.ThenFetch(o => o.Product)
.ThenFetch(o => o.Category)
.ToList();
Assert.AreEqual(830, list.Count);
}
The test completed in 1557ms, where 97ms was spent inside SessionIdLoggingContext:

By replacing AsyncLocal with ThreadLocal as it was prior the async addition, the SessionIdLoggingContext disappears from the radar, which proves that AsyncLocal is way slower than ThreadLocal and we should use it only when necessary.
In order to avoid those penalities for consumers that don't use it, I think that we should provide a way to disable it (e.g. by adding a simple flag on the class itself).