AgentM

Indeed, I think that this is one area where the streaming tuples should make a big difference. Currently, we read tuple expressions from disk all-at-once, so I can see how...

Ah, I found some low-hanging fruit. While Project-M36 creates tuples with shared attributes, when reading them, it ends up with loads of duplicate attributes (one for each tuple), wasting the...

@YuMingLiao , could you take the 105 branch for a spin? In my example testing using "OnDiskClient", the branch reduces memory usage by an order-of-magnitude by sharing a single Attributes...

To be clear, you will need to recreate the db from scratch since this changes the layout on-disk.

Oops, sorry. OnDiskClient is now pushed to the branch. Before the patch, when we create tuple sets, each tuple references one shared `Attributes` blob. However, during deserialization, the attributes would...

I have further reduced the memory and CPU cost of Merkle hash validation. Could you take this branch for another spin? Using OnDiskClient, with 100,000 tuples, the on disk storage...

Hopefully, the improvements to the hashing should reduce the memory ceiling by another order-of-magnitude.

Great! I'll merge this in. There is more low-hanging fruit here, but these ratios are pretty good for now. Expect further improvements to performance and memory usage once the streamly...

I'm not certain that we are encountering the same issue with streamly 0.10.0 and [curryer-rpc](https://hackage.haskell.org/package/curryer-rpc-0.3.3), but after upgrading from streamly 0.9.0, we are seeing reproducible corruption on TCP communications with...

There's actually a more natural way to represent graphs in the relational algebra which I have not seen before. It's not quite possible in Project:M36 because we don't support recursive...