Hi,

Are you talking about any tracing, or just startup tracing?
AFAIK, "netlog" is in the default categories that are enabled, so isn't this the expected behavior? Note that the CL linked above adds a test to check that if the trace config has "-netlog", then netlog events are not recorded.


Should we rename "netlog" to "disabled-by-default-netlog"?

I am not very familiar with netlog. So here is my understanding. Let me know if I am wrong.

So there are two things: netlog and tracelog. For tracelog, as long as you have "-netlog", no net log events will be recorded. But that is separate from netlog. My question is that is netlog turned on by trace log being enabled?
1. if netlog is always turned on and not dependent on trace log, that's fine.
2. if netlog is not always turned on, will TraceNetLogObserver::OnTraceLogEnabled() turn it on or something a like? So it seems to me it just adds an observer to net log and does not affect netlog's behavior. If that is the case, then it is totally fine.

And I am fine netlog being in the default category.

+ Internals>Network>Logging so NetLog owners can comment as well. 

NetLog emits events if there is at least one NetLog observer. When tracing is turned on, it adds itself as an observer to NetLog.

So if tracing is enabled and no other NetLog observer is registered, tracing will make NetLog emit events. 

Re#3, if that is the case, I think tracing should only be added to NetLog as an observer when tracing is on and netlog category is enabled.

Is there an API to check whether netlog category is enabled?

Re #3-4: Yes, this is what I saw from the code. I don't know whether that's a big issue though, since it's consistent with trace events being ignored when the corresponding tracing category is not enabled. Is there anything specific that makes you wary of enabling netlog?

Re #5: I think the following is what you need:

base::trace_event::TraceLog::GetInstance()->GetCurrentTraceConfig().IsCategoryGroupEnabled("netlog")

Re #6: For tracing, if a category is not enabled, it is very lightweight and there is minimal overhead (there is a fast path for that). So if tracing does not want to enable netlog, on the tracing side, ignoring netlog is very fast. And we do not want to introduce overhead to make netlog run, but not use it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be0aa5179a641f9b087b119177be0ea26472358f

commit be0aa5179a641f9b087b119177be0ea26472358f
Author: lizeb <lizeb@chromium.org>
Date: Mon Dec 05 18:57:33 2016

netlog: Don't enable recording if the "netlog" tracing category is disabled.

NetLog enables recording whenever an observer is
registered. TraceNetLogObserver would always register an observer, even
if the "netlog" tracing category is disabled. This is wasteful, since in
this case the trace events are dropped by TraceLog.

This CL only registers the observer when the category is enabled.

BUG= 670732 

Review-Url: https://codereview.chromium.org/2554483002
Cr-Commit-Position: refs/heads/master@{#436368}

[modify] https://crrev.com/be0aa5179a641f9b087b119177be0ea26472358f/net/log/trace_net_log_observer.cc
[modify] https://crrev.com/be0aa5179a641f9b087b119177be0ea26472358f/net/log/trace_net_log_observer_unittest.cc

Thanks!