Extend caching and pooling for better performance

[axunonb]

Extend caching and pooling for better performance

[axunonb]

Ah, yeah, didn't consider this. I'll take a deeper look. My first idea was a First-in/First-out when reaching max. size.
(Existing type cache is also implemented as simple dictionary.)

[axunonb]

Just ported https://github.com/NLog/NLog/blob/dev/src/NLog/Internal/Collections/MruCache.cs - looks good. I think I'm gonna go for that😉

[axunonb]

Got it working with an YAXSerializer object pool.

Results are promising - about 6x faster with 6x less GC pressure compared to the current v4 branch:

|                    Method |    N |      Mean |    Error |   StdDev |     Gen 0 | Allocated |
|-------------------------- |----- |----------:|---------:|---------:|----------:|----------:|
| NoPool_NoWrapperCache_V4  |  500 |  83.19 ms | 0.941 ms | 0.834 ms | 4000.0000 |     35 MB |
| NoPool_NoWrapperCache_V4  | 1000 | 164.48 ms | 1.682 ms | 1.573 ms | 8000.0000 |     71 MB |
|-------------------------- |----- |----------:|---------:|---------:|----------:|----------:|
| With_Pool_WrapperCache    |  500 |  14.12 ms | 0.281 ms | 0.438 ms |         - |      6 MB |
| With_Pool_WrapperCache    | 1000 |  28.84 ms | 0.561 ms | 0.690 ms | 1000.0000 |     13 MB |

Cache and Pool both have limits in size now. Actually, the pool is rather small: only 12 items across all unit tests, but used with a high frequency.

[axunonb]

@304NotModified After having the MemberWrapperCache working, this looks quite nice already:

// * Summary *

BenchmarkDotNet=v0.13.0, OS=Windows 10.0.22000
AMD Ryzen 9 3900X, 1 CPU, 24 logical and 12 physical cores
.NET SDK=6.0.301
  [Host]   : .NET 6.0.6 (6.0.622.26707), X64 RyuJIT
  .NET 6.0 : .NET 6.0.6 (6.0.622.26707), X64 RyuJIT

Job=.NET 6.0  Runtime=.NET 6.0

|                    Method |   N |     Mean |   Error  |   StdDev |     Gen 0 |   Gen 1 | Gen 2 | Allocated |
|-------------------------- |---- |---------:|---------:|---------:|----------:|--------:|------:|----------:|
| WithMemberWrapperCache    | 100 |  4.06 ms | 0.075 ms | 0.070 ms |  437.5000 |  7.8125 |     - |      4 MB |
| WithoutMemberWrapperCache | 100 | 17.77 ms | 0.350 ms | 0.327 ms | 1125.0000 | 62.5000 |     - |      9 MB |

This is includes creating a new YAXSerializer instance in each iteration:

[Benchmark(Baseline = false)]
public void WithoutMemberWrapperCache()
{
    for (var i = 0; i < N; i++)
    {
        _serializer = new YAXSerializer(typeof(YAXLibTests.SampleClasses.MoreComplexExample), new SerializerOptions {
            ExceptionHandlingPolicies = YAXExceptionHandlingPolicies.DoNotThrow,
            ExceptionBehavior = YAXExceptionTypes.Warning,
            SerializationOptions = YAXSerializationOptions.SerializeNullObjects
        });
        _ = _serializer.Serialize(_sampleClass);
    }
}

When iterating with only one class variable instance, speed drops with every iteration and memory consumption goes up. Even N = 100 takes ages to complete. Running the sample as unit tests completed fast, though. Sth. wrong with the performance test test setup, I guess.

[304NotModified]

Cool stuff. But is there a max cache size? Or what happens if there is a memory shortage?

[axunonb]

No, currently there is no max cache size. This has no issues even after running all unit tests, where all class members go to the static cache. Didn't check yet how big it is then. You think the cache size should be limited?

[304NotModified]

Yes otherwise you could get memory leaks or out of memory issues.

[304NotModified]

Maybe we could do something with https://docs.microsoft.com/en-us/dotnet/core/extensions/caching

Or https://github.com/NLog/NLog/blob/dev/src/NLog/Internal/Collections/MruCache.cs (also tests there)

[axunonb]

@304NotModified Just checked the number of recursions that happen across all unit tests and using method YAXSerializer.NewInternalSerializer
With every counted recursion, a new YAXSerializer is created.
A YAXSerializerPool might bring a gain in speed and less GC pressure, wouldn't it?
After a first trial this seems not so easy to implement...

Group             Count
9 Recursions =   110168
8 Recursions =      326
7 Recursions =     2293
6 Recursions =      126
5 Recursions =      963
4 Recursions =       26
3 Recursions =       52
2 Recursions =      168
1 Recursion  =     1106

Total Count  =   115228

[axunonb]

Resolved with release v4.0.0