Add comparsion to tinylog

[koppor]

Thank you for spending energy to a modern logging framework.

At https://github.com/jstachio/rainbowgum?tab=readme-ov-file#comparison-to-other-frameworks, I miss a comparison to tinylog2, which also has similar goals (IMHO).

[agentgt]

Tagging @pmwmedia to keep me honest and for corrections:

Yes I saw tinylog a long time ago as 1.0 and I forgot to add it to the list. Great library!

For now the major difference is tinylog like its name focuses on being "tiny" and rainbowgum is focused on being "small" in core and modular as well as exploiting as much of modern JDK offerings.

Rainbow Gum also focuses on having faster initialization, strong programmatic options for configuration and doing various optimizations because of invariants as well as static code generation (annotation processor).

For example the programmatic configuration for Tinylog is filling a Map<String,String> with not-javadoc-ed properties. They should have those properties as public static constants somewhere at the minimum but even then it is not type-safe like Rainbow Gums builders. Tinylog's requirement of config is Map<String,String> where as Rainbow Gums is Function<String,String>. The former allows somewhat easier config as you can look at all the keys but the latter can be used with more config systems perhaps with 1000s of keys.

Tinylog is less componetized and like logback prefers inheritance and large classes to do multiple things which is the case with its Writers. There are pros and cons to this approach.

Rainbow Gum's builders and composition over inheritance come at a cost of more classes and is most likely why its core is bigger than all of Tinylog (which massive kudos for tinylog on that). Just to give an example. Say there is a composite like component that has a list of tinylog writers. The natural solution would be to have that as one class that always iterates over that list. Rainbow Gum does not do that. It has "single" version that will not iterate over a list and this is resolved through static factory methods. Again this is why rainbow gum is bigger because it has more implementations of these components where something like logback and tinylog would only have one implementation and rely on the JIT to make the eventual optimization.

An example of eager optimization in terms of loggers is best to use tinylogs custom logging api example: https://tinylog.org/v2/extending/#custom-logging-api

Tinylog recommends this:

package org.tinylog.example;

import org.tinylog.Level;
import org.tinylog.provider.LoggingProvider;
import org.tinylog.provider.ProviderRegistry;

public class MyLogger {

    private static final LoggingProvider provider = ProviderRegistry.getLoggingProvider();

    private static final int minimumLevel = provider.getMinimumLevel(null).ordinal();
    private static final boolean infoEnabled = minimumLevel <= Level.INFO.ordinal();
    private static final boolean errorEnabled = minimumLevel <= Level.ERROR.ordinal();

    public static void info(String message) {
        if (infoEnabled) {
            provider.log(2, null, Level.INFO, null, null, message);
        }
    }

    public static void error(Throwable exception) {
        if (errorEnabled) {
            provider.log(2, null, Level.ERROR, exception, null, null);
        }
    }

}

Rainbow Gum on the other hand literally has a class for each level such that the error logger is literally:

    public static void info(String message) {
    }

    public static void error(Throwable exception) {
        provider.log(2, null, Level.ERROR, exception, null, null);
    }

While the above doesn't actual exist in Rainbow Gum because static method logging is not common so its best to compare the SLF4J logger implemntations:

That is compare:
https://github.com/tinylog-org/tinylog/blob/v2.7/slf4j-tinylog/src/main/java/org/tinylog/slf4j/ModernTinylogLogger.java

https://github.com/jstachio/rainbowgum/blob/main/rainbowgum-slf4j/src/main/java/io/jstach/rainbowgum/slf4j/LevelLogger.java

Another example of this eager optimization is that Tinylogger and others only have one implementation of their "event". Rainbow Gum has several based on static factories and this to reduce unnecessary memory usage as there is no way events are going to be EA (escape analysis). That being said its unlike Rainbow Gum will ever add line number and method name to events as more often than not people forget to turn that off in production and in dev people can and should just use a debugger.

Tinylog I think uses a fair amount of synchronized (I need to double check this) which is problematic with virtual threads but what is something I think the should change is they capture the literal Thread object in the event which was okay in traditional thread pools but with virtual threads where you want those GC as fast as possible I think that is not a good idea.

Tinylog custom service loader approach (it allows more than no-arg constructors) while novel I'm not sure how well it works in a modular environment. I assume it would but not sure. That is I'm not sure if the provides ... with ... just makes single class entirely open or are there more rules like only a public constructor. Furthermore because Rainbow Gum uses URI schemes instead of class names of the service provider one can replace the builtin default Outputs (writers in tinylog). That is you can have your own File Output and it will be used instead of the default. Its unclear if that is possible in tinylog and or how it deals with duplicate getSimpleName().

Speaking of ServiceLoader TinyLog on its next version should make a single SPI interface so that it only makes once ServiceLoader call instead of a call for each type of component. For example there is a META-INF/services/org.tinylog.writers.Writer and META-INF/services/org.tinylog.throwable.ThrowableFilter. The ServiceLoader call is actually an expensive operation at initialization as it has to do resource lookup. Rainbow Gum only makes one call.

One of my favorite things in the Tinylog doc is how they format the java.util.Properties with the = lined up and that custom service loader approach makes it look even nicer. I may have to borrow that formatting for my properties part of the doc.

Anyway its a great library and its why I did such an in depth analysis.

[agentgt]

Benchmark                                      (async)          (locationInfo)  Mode  Cnt  Score   Error  Units
o.t.b.l.logback_.Logback_Benchmark.output        false                    NONE    ss    9  2.510 ± 0.314   s/op
o.t.b.l.logback_.Logback_Benchmark.output        false  CLASS_OR_CATEGORY_ONLY    ss    9  2.741 ± 0.131   s/op
o.t.b.l.logback_.Logback_Benchmark.output        false                    FULL    ss    9  8.990 ± 0.225   s/op
o.t.b.l.logback_.Logback_Benchmark.output         true                    NONE    ss    9  0.284 ± 0.015   s/op
o.t.b.l.logback_.Logback_Benchmark.output         true  CLASS_OR_CATEGORY_ONLY    ss    9  0.303 ± 0.047   s/op
o.t.b.l.logback_.Logback_Benchmark.output         true                    FULL    ss    9  4.848 ± 0.037   s/op
o.t.b.l.rainbowgum.RainbowGumBenchmark.output    false                    NONE    ss    9  0.335 ± 0.017   s/op
o.t.b.l.rainbowgum.RainbowGumBenchmark.output    false  CLASS_OR_CATEGORY_ONLY    ss    9  0.381 ± 0.012   s/op
o.t.b.l.rainbowgum.RainbowGumBenchmark.output    false                    FULL    ss    9  0.375 ± 0.011   s/op
o.t.b.l.rainbowgum.RainbowGumBenchmark.output     true                    NONE    ss    9  0.284 ± 0.026   s/op
o.t.b.l.rainbowgum.RainbowGumBenchmark.output     true  CLASS_OR_CATEGORY_ONLY    ss    9  0.334 ± 0.023   s/op
o.t.b.l.rainbowgum.RainbowGumBenchmark.output     true                    FULL    ss    9  0.320 ± 0.039   s/op
o.t.b.l.tinylog2.Tinylog2Benchmark.output        false                    NONE    ss    9  2.398 ± 0.113   s/op
o.t.b.l.tinylog2.Tinylog2Benchmark.output        false  CLASS_OR_CATEGORY_ONLY    ss    9  3.345 ± 0.156   s/op
o.t.b.l.tinylog2.Tinylog2Benchmark.output        false                    FULL    ss    9  3.797 ± 0.590   s/op
o.t.b.l.tinylog2.Tinylog2Benchmark.output         true                    NONE    ss    9  0.314 ± 0.288   s/op
o.t.b.l.tinylog2.Tinylog2Benchmark.output         true  CLASS_OR_CATEGORY_ONLY    ss    9  1.024 ± 0.070   s/op
o.t.b.l.tinylog2.Tinylog2Benchmark.output         true                    FULL    ss    9  1.283 ± 0.017   s/op

I must be doing something wrong. There is no way Rainbow Gum is that much faster. I kept think it was slower because it is "s/op".

https://tinylog.org/v2/benchmark/

[koppor]

@agentgt Thank you for the quick and impressive action taken. I wonder whether some of the result can be included at https://github.com/jstachio/rainbowgum?tab=readme-ov-file#comparison-to-other-frameworks?