«

On Monday, January 28, 2013 1:32:32 AM UTC-8, Mikhail Vladimirov wrote:
> > So just by doing what I already do I get absolutely everything you tout
>
> > as an advantage of your new logging system.
>
> Main advantage of ultralog is an ability to substitute variables into log messages without allocating new objects, yet having readable code. This advantage cannot be achieved on top of log4j because log4j allocates temporary objects internally.

You keep touting "advantages" that your potential users state as not very helpful,
or not superior to existing tools.

Your sense of "advantages" is irrelevant to marketing. The market's sense is what matters
and all that matters.

Arguing with prospects does not make them customers.

Good luck with that. The answers you've given others in this thread have convinced me
unequivocally to avoid your project.

Good job.

--
Lew

> You keep touting "advantages" that your potential users state as not very helpful,
> or not superior to existing tools.
> Your sense of "advantages" is irrelevant to marketing. The market's sense is what matters
> and all that matters.
Ultralog focuses on demands of high performance applications, which is quite a narrow market. Advantages of ultralog may be helpless outside high performance domain.

Mikhail Vladimirov wrote:
> [attribution restored] Lew wrote:
>> You keep touting "advantages" that your potential users state as not very helpful,
>> or not superior to existing tools.
>
>> Your sense of "advantages" is irrelevant to marketing. The market's sense is what matters
>> and all that matters.
>
> Ultralog focuses on demands of high performance applications, which is quite a narrow market. Advantages of ultralog may be helpless outside high performance domain.

Made me wrong again, huh, Dale Carnegie?

I think your market might be considerably narrower than you imagine.

--
Lew

> In what way? Which benefits do Ultralog bring to the table for high
> performance applications re logging?
The most important things are:
1. Garbage-free logging. You can format and send out log message without allocating any new objects.
2. Lock-free logging. you can format and send out log message without acquiring any locks.
3. Log message templates are compiled into Java bytecode in run time or even in compile time, which makes message formatting really fast.

Check ultralog WiKi for more details: http://code.google.com/p/ultralog/wiki/TableOfContents

On 1/29/2013 2:34 PM, Mikhail Vladimirov wrote:
>> In what way? Which benefits do Ultralog bring to the table for high
>> performance applications re logging?
> The most important things are:
> 1. Garbage-free logging. You can format and send out log message without allocating any new objects.
> 2. Lock-free logging. you can format and send out log message without acquiring any locks.
> 3. Log message templates are compiled into Java bytecode in run time or even in compile time, which makes message formatting really fast.
>
> Check ultralog WiKi for more details: http://code.google.com/p/ultralog/wiki/TableOfContents

Any measurements of the impact for some realistic code?

Arne

>> 1. Garbage-free logging. You can format and send out log message without allocating any new objects.
>> 2. Lock-free logging. you can format and send out log message without acquiring any locks.
>> 3. Log message templates are compiled into Java bytecode in run time or even in compile time, which makes message formatting really fast.
> Any measurements of the impact for some realistic code?
The idea that high-performance application may want to process data withoutproducing garbage is not something new. Check, for example, this link: http://oreilly.com/catalog/javapt/chapter/ch04.html

The same could be said about lock-free design. It is well known approach to increase performance of multi-threaded applications.

Ultralog is not the first Java library designed to be garbage- and lock-free and focused on demands of high performance applications. See, for example, LMAX Disruptor: http://lmax-exchange.github.com/disruptor/ It is all about hot to avoid lock and garbage creation and it states itself as "High Performance Inter-Thread Messaging Library".

Ultralog is even not the first attempt to create garbage-free logging framework for Java. See, for example, the following link: https://bitbucket.org/vladimir.dolzh...gger/wiki/Home It states its goal as "to create ad-hoc logger for low latency (latency critical) applications (to be precise for latency critical execution path) which will affect application explicitand implicit (though gc pauses) as less as it possible". It does not claim itself to be lock-free though.

What is new in ultralog in comparison with gflogger, is that it demonstrates that garbage-free logging could be done without sacrificing code readability.

Mikhail Vladimirov wrote:

DUDE! Attribute quotes!

Please.

Arne wrote:
>> Any measurements of the impact for some realistic code?
>
> The idea that high-performance application may want to process data without producing garbage is not something new. Check, for example, this link: http://oreilly.com/catalog/javapt/chapter/ch04.html
>
> The same could be said about lock-free design. It is well known approachto increase performance of multi-threaded applications.
>
> Ultralog is not the first Java library designed to be garbage- and lock-free and focused on demands of high performance applications. See, for example, LMAX Disruptor: http://lmax-exchange.github.com/disruptor/ It is all about hot to avoid lock and garbage creation and it states itself as "High Performance Inter-Thread Messaging Library".
>
> Ultralog is even not the first attempt to create garbage-free logging framework for Java. See, for example, the following link: https://bitbucket.org/vladimir.dolzh...gger/wiki/Home It states its goal as "to create ad-hoc logger for low latency (latency critical) applications (to be precise for latency critical execution path) which will affect application explicit and implicit (though gc pauses) as less as it possible". It does not claim itself to be lock-free though.
>
> What is new in ultralog in comparison with gflogger, is that it demonstrates that garbage-free logging could be done without sacrificing code readability.

In other words, no, no measurements.

--
Lew

> 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.

Once application is decided, for whatever reason, to be garbage-free, whichmeans 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.

Performance tests I have shows that ultralog is usually not slower than System.out.println() and is not slower than log4j.

Mikhail Vladimirov wrote:

Still not attributing quotes, I see.

> [Lew 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.

Of course it is, because you have no answer for this so you want to ban thequestion.

You're not convincing me you're anything but a con artist with such tactics..

> 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.

Why not? What other benefit does avoiding GC provide?

> Performance tests I have shows that ultralog is usually not slower than System.out.println() and is not slower than log4j.

That tells us nothing. What sort of "performance" tests? Under what protocols? And "not slower" than
'println()' is useless; we already know log4j is generally less impactful on performance than the
'System.out' technique. "Not slower" than log4j, even if your tests are notjust crocks of porcine
excrement, is not impressive.

You have yet to tout a real benefit. You get diversionary when people ask about your benefits.
You were asked about "any impact" (beneficial or otherwise) and you chose to interpret it as
a question about performance, then tried to claim that performance, the topic you introduced,
was off topic.

And again, when potential users ask about things that matter to them, you try to tell them that
their concerns are not valid. That's shitty marketing.

I think that your product, far from being garbage free, is nothing but garbage, based on what
you've told us and how you disrespect us.

--
Lew

> Still, never mind, at least you're trying to do something constructive.
Lew is doing good work bumping this discussion up. This is why I'm feeding the troll