I'm excited to share the new release of the 0.7.x series for Penna!

What is so special about this release?

Well, this one mainly reworks the internal logger storage and it allows for great improvements on the configuration side!

How was the structure before?

Before this release, Penna would store the loggers' references in a tree structure. This means, for example that if your app had multiple loggers for a certain package, they'd be sitting side-by-side in the same parent node. The way it was modeled before was like something this:

private record Node(
            String[] identifier,
            LoggerConfigRef ref, // reference to either a logger, a config or none.
            List<Node> children,
            Lock lock) { ... }

A few things to note:

• String[] was used to store each component, so sh.polar.MyApp would be the same as new String {"sh", "polar", "MyApp"};
• Each node would contain a list of children, so traversing a path means at every step when traversing the path you have to look for the identifier that matches in a linear search among the node's children;

Why was it a problem?

Well, although it wasn't particularly slow, it was costly. Also, the API had to accommodate the String[] usage that was just weird.

How does the new storage looks like?

The new storage is using a Ternary Search Tree data structure, which sits somewhere between a tree and a trie. The difference between a traditional TST and our implementation is that instead of storing characters, it stores logger name components, so sh.polar.MyApp would have the three sh, polar and MyApp nodes stored.

Compared to the previous tree structure, it proved to be much faster.

Another fundamental difference is the use of a StringNavigator to search for the right node, instead of splitting the string in individual chunks into an array and iterating over the indexes of an array to find the right element. This saves a considerable amount of memory as it operates on the same string element, without duplicating memory objects.

As a result, the API is much nicer to work with as it can safely take a namespace-like string and still efficiently navigate through the TST storage to obtain the correct logger.

Awesome! What's next?

Next up is likely starting off the 0.8.x series and take Penna closer to 1.0!

If you're interested in lower-level interactions like this, consider the premium subscription as I'll be talking in detail about ongoing changes during this and next development series through premium-only posts!

Also, as I want to make Penna's development more transparent and listen to public feedback, I've opened up a poll in Penna's github discussions. Even if you don't use Penna, I'd love to hear your thoughts!

So long and see you next time!