Reduced some allocations in QRCodeGenerator (NETCORE_APP only)

[gfoidl]

Profiling showed that there are some allocations in QRCodeGenerator that can be quite easily avoided.

simple console app for profiling

using System.Diagnostics;
using QRCoder;

string payload = $"""
    Time    : {DateTimeOffset.Now:O}
    Machine : {Environment.MachineName}
    Activity: {Activity.Current?.RootId}
    """;

int len = 0;

for (int i = 0; i < 1_000; ++i)
{
    string imgSrc = GetQRCode("sdfsdf");
    len += imgSrc.Length;
}

Console.WriteLine(len);

static string GetQRCode(string payload)
{
    using QRCodeGenerator qrCodeGenerator = new();
    using QRCodeData qrCodeData = qrCodeGenerator.CreateQrCode(payload, QRCodeGenerator.ECCLevel.Q);
    using Base64QRCode qrCodeBase64 = new(qrCodeData);
    string base64QRCode = qrCodeBase64.GetGraphic(20);
    return $"data:image/png;base64,{base64QRCode}";
}

Allocations are removed / avoided for:

• Dictionary<,>.Entry[]
• QRCodeGenerator.PolynomItem[]
• Dictionary<,>

The change is done only for .NET (Core) targets, as Span<T> is used.
By adding a reference to System.Memory package this change could also be done for .NET Desktop.

Profile

Before

After

Benchmarks

Before

| Method              | Mean        | Error     | StdDev    | Gen0   | Allocated |
|-------------------- |------------:|----------:|----------:|-------:|----------:|
| CreateQRCode        |    235.2 μs |   4.50 μs |   5.00 μs | 2.1973 |    7.2 KB |
| CreateQRCodeLong    |  2,684.9 μs |  48.00 μs |  44.89 μs | 7.8125 |  33.25 KB |
| CreateQRCodeLongest | 16,264.4 μs | 317.90 μs | 485.47 μs |      - |  79.69 KB |

After

| Method              | Mean        | Error     | StdDev    | Gen0   | Allocated |
|-------------------- |------------:|----------:|----------:|-------:|----------:|
| CreateQRCode        |    232.0 μs |   4.63 μs |   6.64 μs | 0.9766 |   4.38 KB |
| CreateQRCodeLong    |  2,574.1 μs |  41.97 μs |  39.26 μs | 3.9063 |     12 KB |
| CreateQRCodeLongest | 15,573.7 μs | 292.90 μs | 259.65 μs |      - |  48.24 KB |

[gfoidl]

Before Linq was used w/ it's generic Contains method.

• for AOT Linq requires way more code
• it's an interface dispatch that isn't needed

Note: for .NET (Core) the span-based Contains is used.

[Shane32]

Do you plan to leave the Debug.Assert code in here? Just wondering; it will get removed from release builds anyway.

[gfoidl]

I like to have some Debug.Asserts

• they check some invariants in debug builds and while running tests
• are a bit of self-documenting the intention (so why write a comment, when the assert can also be done?)

Especially here the buffer is passed in as argument and must have the correct size.
If the size doesn't match, then the tests (under debug) will fail and one knows why. Otherwise it may be hard to track down the bug.

So I'd leave them in the code.

As you said: for !DEBUG these asserts won't have any effect.

[Shane32]

By adding a reference to System.Memory package this change could also be done for .NET Desktop.

I wouldn't. There has been so many performance enhancements in .NET Core since .NET Framework, that if anyone wants better performance, they should use .NET Core. And I'm sure the fallback performance is plenty good enough anyway.

[Shane32]

The reduction in allocations is very impressive!

[Shane32]

I fixed the CI scripts in #592 btw

[Shane32]

Looks good to me! (subject to tests passing, of course)

[gfoidl]

I fixed the CI scripts in #592 btw

Should that change be separated into a own PR to fix CI?

Otherwise every PR has to re-do the same until your PR gets merged.

---

@Shane32 thanks for your review and comments 👍🏻

[Shane32]

Should that change be separated into a own PR to fix CI?

Honestly yes…

[gfoidl]

Found some more allocation that can be quite easily avoided.

| Method              | Mean        | Error     | StdDev    | Gen0   | Allocated |
|-------------------- |------------:|----------:|----------:|-------:|----------:|
| CreateQRCode        |    240.0 μs |   4.57 μs |   4.89 μs | 1.2207 |   4.07 KB |
| CreateQRCodeLong    |  2,730.3 μs |  41.85 μs |  37.10 μs |      - |  11.05 KB |
| CreateQRCodeLongest | 17,367.9 μs | 345.33 μs | 657.03 μs |      - |  46.42 KB |

(note: time column isn't really comparable to results in top post (different machine), so only allocations count here)

[gfoidl]

The downside of Linq is that no (generic) state can be passed in, thus a closure is needed, and this one showed up in a memory-profile.

[gfoidl]

This closure also showed up, and unfortunately the closure (display-class) gets created at method entry, and not when actually needed, so we have to work around this.