Re: ultralog: new concept of logging API
On 1/30/2013 2:19 AM, Mikhail Vladimirov wrote:
In other words, no, no measurements.
I think that discussion about why one may want to make applications
garbage-free and why garbage-free applications may perform faster and
how much faster they can perform is off-topic here.
No.
If your argument for why your logger is better than the common
ones is that it is faster, then it is very on topic to ask
how much it is faster.
If it is 1% faster then the interest may not be so big. If it is
50% faster then a lot of people could be interested in trying it.
Once application is decided, for whatever reason, to be garbage-free,
which means that normal data processing flow in the application does
not allocate any temporary objects, and once normal data processing
flow involves logging, the application has to use some garbage-free
logging solution, either home-grown or third party. In this case
mainstream logging frameworks simply does not fit, because they are
not garbage-free. Ultralog demonstrates how API for garbage-free
logging framework can be structured without sacrificing code
readability. It does not need to be faster than mainstream
frameworks and switching to ultralog in application that is not
garbage-free itself should not necessarily lead to performance
benefit.
If one has religious beliefs against GC then a GC free app
certainly makes sense.
But otherwise it would be the actual difference in performance (and
performance characteristics) that matter.
Performance tests I have shows that ultralog is usually not slower
than System.out.println() and is not slower than log4j.
That does not sound good for you.
If your supposed faster logger is not faster, then it is pretty\
difficult to argue to switch to it.
Arne