Create optimized Fressian handlers for tokens and elements

[WilliamParker]

Currently Clara elements and tokens use a general Fressian handler for arbitrary Clojure records. This works, but is likely suboptimal for performance. This includes both things that impact records in general and things specific to elements and tokens due to the structure of their contents. Due to the sheer number of tokens and elements that can exist in large rules sessions I believe these optimizations have the potential to significantly improve performance of the Fressian durability implementation.

1. Since the handler is built for arbitrary record types, it has to serialize the record with the name of its constructor function as seen here. After deserialization, this name is then used as a symbol to resolve the function. We've seen these calls to clojure.core/resolve be a hotspot during session deserialization. Furthermore, the function name obviously takes up space in the serialized session.
2. Since the record is serialized as an arbitrary map here we have to serialize the keys, which takes space in the serialized session although probably not much since they are cached. Deserializing the keys takes time as well. Furthermore, when reading the record we create a map of the contents that are then passed to the constructor function here. Since this map is not used once the record is created, it would be more efficient to use something that could call the token or element's positional constructor without needing to build this map.
3. We know that we don't use metadata on tokens or elements but we still serialize and deserialize an empty map for them.
4. There are places where we it may make sense to use caching with an InternalMemIdx marker on structures where it doesn't make sense in general for records. In particular, many of the tuples inside the :matches of tokens can be expected to be identical to other such tuples due to the many places in the engine where we take the existing vector of :matches and conj on a new one to build a new token, such as here. Bindings maps could benefit in some cases as well, although probably not as much as token match tuples. For example, RootJoinNode just takes a binding map from an element and uses it in a token here.

[mrrodriguez]

Many of these Fressian optimizations are very general. Looking back, it almost seems to me that a entirely different library could have been pulled out from clara-rules to do these Fressian handler-specific things.

When serializing with Fresssian to and from a Clojure consumer, these handlers are helpful. I do not alternative open-source libraries out right now that provide these types of Fressian handlers.

Just a thought for perhaps a future branching point.

If I were to do it over again, I definitely would have put the Fressian handlers in a separate project. The reason I didn't originally is because I didn't want to add that sort of dependency to clara-rules project for this. However, all of the Fressian stuff is optional for consumers still.

[dimovich]

Recently was looking for a library for fressian handlers for common clojure data types, and couldn't find one. Thanks for the blog post. I ended up extracting a part of the code to a separate library.

I had some issues using core.async with ThreadLocal. Even though I bind it with thread-local-binding, it's not visible from inside a go block. So had disable the object caching.

[mrrodriguez]

@dimovich My concern with the new impl is that tthe identity based caching is a fairly significant part of the original impl, both for performance & possibly correctness (depending on your case).

The identity-based cache preserves the identical? relationship of objects during deserialization that was present during serialization. It also reduces the size of the serialization stream since the identity indexes are much smaller than writing whole objects out again.

I'm sure there could be issues using core.async, but I'm wanting to better understand how you are trying to perform this sort of serialization in core.async to try to get some understanding of what wouldn't work?

[dimovich]

@mrrodriguez For my use case the data is heterogeneous, and there aren't noticeable gains in file size for using the caching. The identity based handler is handy when there is repeating data, which seems to be the case for clara-rules.

Here is an example gist of using core.async with ThreadLocal.
It gives a NullPointerException.

An older discussion about binding and core.async.

Here is an attempt of passing the cache as a parameter instead. Works fine with core.async.

[mrrodriguez]

@dimovich interesting. Thanks for the references. I'll have to take a look closer at your core.async stuff.

I suppose if you do not have much repeated data references then it wouldn't matter as much indeed. Clara certainly has many cases of the same elements being in many collections etc.