Mojo::Log levels Trace & Debug.

[ajmetz]

Hi - any style guidance on when to use trace and when to use debug, as regards Mojo::Log or similar?
I generally need to trace steps when I'm debugging my code. So should the logging for that purpose be using debug, because I'm debugging, or trace, because I'm tracing where we got up to before an error?

If they are just labels and it's up to you how you use them,
then some examples of how others have made a distinction in their mojolicious apps, would be insightful.

Yours gratefully,
Andrew.

[ajmetz]

I see here the levels are listed in an order:

https://docs.mojolicious.org/Mojo/Log#level

I'm guessing then that trace is to be more finegrained than debug?

[Grinnz]

Yes. If you have log_level=trace you will see both trace and debug messages, if you have log_level=debug you will not see trace messages.

The general intent is that debug is debugging information, and trace is verbose details of each occurrence whether or not it may be relevant (so it can be used to trace the cause of an issue).

[s1037989]

Is there much performance impact to having lots of trace calls in production code but log level set lower? Or is the intent for debug and trace calls to not be merged into production code?

…

On Thu, Mar 26, 2026, 2:48 PM Grinnz ***@***.***> wrote: Yes. If you have log_level=trace you will see both trace and debug messages, if you have log_level=debug you will not see trace messages. The general intent is that debug is debugging information, and trace is verbose details of each occurrence whether or not it may be relevant (so it can be used to trace the cause of an issue). — Reply to this email directly, view it on GitHub <#2309?email_source=notifications&email_token=AAD6K6XEC4SC7PUNJYZ64CT4SWCSNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGMZDEOBTUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-16332283>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD6K6UCR4IUHUV4XWU2DIL4SWCSNAVCNFSM6AAAAACXA6BC7CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZTGIZDQMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ajmetz]

I assume they simply don't get logged if you run your mojolicious app in production mode,
and do if you run it in development mode. Let's see what the docs say...
https://docs.mojolicious.org/Mojolicious/Guides/Tutorial#Mode

A mode other than development will raise the log level from trace to info. All messages will be written to STDERR by default.

[Grinnz]

The performance impact would be it deciding each time whether the log level matches, and the code being run to some extent whether it matches the log level or not. This shouldn't be prematurely optimized, but may have an impact in hot paths, which can be solved by using constant folded conditions and loggers that optionally take anonymous subs to form the log message, which isn't anything that Mojo::Log implements.

[Grinnz]

Correcting myself, because Mojo::Log actually does accept logging anonymous subs, which you can use if your log messages are costly to assemble.

[s1037989]

Correct, but the call is still made to check the log level. So I'm curious what impact on performance that has and if recommendation is to merge those lines to production or not.

…

On Thu, Mar 26, 2026, 3:55 PM ajmetz ***@***.***> wrote: I assume they simply don't get logged if you run your mojolicious app in production mode, and do if you run it in development mode. Let's see what the docs say... https://docs.mojolicious.org/Mojolicious/Guides/Tutorial#Mode A mode other than development will raise the log level from trace to info. All messages will be written to STDERR by default. — Reply to this email directly, view it on GitHub <#2309?email_source=notifications&email_token=AAD6K6VDX7LNH4YFIKTNU7L4SWKKJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGMZDQNRZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16332869>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD6K6UPSY3ZDTUGVWZRMET4SWKKJAVCNFSM6AAAAACXA6BC7CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZTGI4DMOI> . You are receiving this because you commented.Message ID: ***@***.***>

[ajmetz]

Hoping Grinnz' answers above address that.
#2309 (reply in thread)

[s1037989]

IMO, yes. I think what @Grinzz is saying is that it's fine to let debug and trace calls be called and immediately aborted throughout production -- what to watch out for is expensive code executions in the calls because they'll be called as evaluations before passed to the aborted log level sub. OK: `app->log->trace('Got input');` # Passing along a string is mostly harmless so let Mojo::Log work Bad: `app->log->trace(sprintf "Got input: %s", factorial(52));` # Calculating 52! on a trace call is going to happen in production when log level is warn

…

On Fri, Mar 27, 2026 at 6:41 AM ajmetz ***@***.***> wrote: Hoping Grinnz' answers above address that. — Reply to this email directly, view it on GitHub <#2309?email_source=notifications&email_token=AAD6K6QTRYUAGA53QZKT2RT4SZSINA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGQZDSNRWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16342966>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD6K6QT3GNNQKF34G7KSO34SZSINAVCNFSM6AAAAACXA6BC7CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZUGI4TMNQ> . You are receiving this because you commented.Message ID: ***@***.***>

[Grinnz]

In most cases yes. In your example you can use the anonymous sub function to avoid this issue like: app->log->trace(sub { expensive calculation here })

If you put enough trace calls in a hot path where calling the logger's trace method each time adds noticeable performance impact, the solution is to use a constant folded condition instead, which Mojo::Log can't handle for you but you could do something like use constant TRACE => !!$ENV{MY_TRACE}; ... app->log->trace(...) if TRACE; and then these lines would all not even be called unless that env var is set.

[s1037989]

Yep, I like that! I've thought about doing that, but it felt redundant -- but I absolutely understand the purpose of doing so! I'm happy to have validation that this isn't a crazy way of thinking! Thanks!

…

On Fri, Mar 27, 2026 at 4:30 PM Grinnz ***@***.***> wrote: In most cases yes. In your example you can use the anonymous sub function to avoid this issue like: app->log->trace(sub { sprintf ... }) If you put enough trace calls in a hot path where calling the logger's trace method each time adds noticeable performance impact, the solution is to use a constant folded condition instead, which Mojo::Log can't handle for you but you could do something like use constant TRACE => !!$ENV{MY_TRACE}; ... app->log->trace(...) if TRACE; and then these lines would all not even be called unless that env var is set. — Reply to this email directly, view it on GitHub <#2309?email_source=notifications&email_token=AAD6K6UAOK5HGJSSDVU2JJD4S3XFZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGUYDINRRUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16350461>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD6K6UHJS7NLWWJVYM4SYD4S3XFZAVCNFSM6AAAAACXA6BC7CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZVGA2DMMI> . You are receiving this because you commented.Message ID: ***@***.***>

[ajmetz]

I've been playing with using Log::Any via the MojoLog adapter. That way, the end result could still be Mojo::Log, however, I could use Log::Any's tracef and debugf, which according to Log::Any documentation won't even pass the log message to the adapter if it's not at the relevant level.
That said, I am just learning logging, and will move on later to async and non-blocking, and I don't know if using Log::Any via a plugin will adversely effect any wish to move to non-blocking async functions further down the line.