Bring Expression Builder To Serializer

[magiccodingman]

Move the expression builder from runtime reflections when executing from deferred execution to instead becoming cached and/or being in the serializer with custom caching. Startup runtime reflections could also capture all execution instances and pre-cache to make things faster.

When bringing the expression builder to the serializer level with caching. It'd be best to build a more robust library for conversions that enforce better practices, allow more possibilities, and make upgrades easier. This refactor could also implement the request #27 for a select statement as well while being in the thick of the process anyways.

• Don't have time to do this now so writing a note on this.

[magiccodingman]

May just do better caching instead to be honest. We'll see. Just want to make this a bit more stable and performant.

[magiccodingman]

Lots of performance and additions made to the expression builder on the JS side but I don't believe I'm going to re-optimize/refactor the current C# expression builder. Currently it's already very performant. And there's only so much that can be done further when optimizing the interop communication level from blazor to JS which is the main bottleneck. New initial calls were recorded on my side around 28 ms. Afterwards when caching occurs it's roughly ~14 ms per call. There's a few more optimizations that could be made, but we're already starting to see the limitations of performance increases we can reasonably achieve anyways because the JS Interop communication layer.

As for the current expression builder. The first time it runs on an expression it takes roughly 32 ms. But on reoccurring calls, the C# JIT compiler has implicit caching which brings the time down to 2ms.

This means complex queries being translated from C#, sent to IndexDB, received back and translated back to C#. The entire process right now is taking ~16 ms with invoked caching. So we are talking about only 16 ms right now that this library is achieving for the entire LINQ to IndexDB process. It's not worth refactoring the expression builder to fight for 2 ms at the moment.

I believe we've gotten this project to a very performant level. Latency is low and we're starting to see the ceiling of what's possible outside of building a library that directly calls browser IndexDB API's. Which this project specifically aimed not to do for maintenance purposes. Which is why I wanted to ride the back of Dexie.JS and their strong community. As many Blazor IndexDB projects have fallen apart trying to maintain browser API's in IndexDB with our very small niche community.