The patch was longer than expected because ifdef'ng the trace macros generated a bunch of unused variable jazz in individual impls that I had to ifdef out.

Confirmed your results by patching in & building locally. Here are some more info about where the size is being saved:

Section Sizes (Total=-914,280 bytes):
.bss: -16,000 bytes (not included in totals)
.data: -16 bytes (0.0%)
.data.rel.ro: -192 bytes (0.0%)
.data.rel.ro.local: -160 bytes (0.0%)
.rodata: -172,704 bytes (18.9%)
.text: -725,208 bytes (79.3%)


Largest by namespace:
* -153,154  content (25322)
* -146,323  {global} (27458)
* -125,221  blink (81190)
* -98,748   cc (4928)
* -89,830   IPC (5540)
* -47,392   gpu (4384)
* -28,251   gl (2209)
* -24,132   base (9638)
* -18,264   media (5553)
* -10,941   device (1894)
* -10,794   net (10091)

Thanks for the patch. Yeah just checked and I see 880 KB in official_build=true. 

Unfortunately I don't think there is anything easy we can do. we need tracing for devtools, for slow-reports, for the heap profiler, getting bugs from partners (all these are production things),  as well as telemetry and local debugging, so we can't just strip out tracing in official builds, or we'd become completely blind to perf. 

If anybody has the time to get the A/B assembly (before/after the patch) for a bunch of functions that use tracing I can try to take a look and see if there is anything that we could improve in the macros.

I poked at a few TRACE_EVENT0 macros with lnsdump, they take about 80 bytes each (for code compiled with -Os), which is a bit large.

One possibility is to play on the performance-size tradeoff for some of these calls. For example, most stuff in /device or even in /content probably does not need to inline the whole call path with multi-level macros. I imagine those could be reduced to 20 bytes or less. That would be ~100K win for /content at the risk of slight regressions and more histogram macro code to support.

Another idea is that .rodata part (the strings) can be hashed to cover the running in production usecases, this would be one more unpleasant moving part.

Complexity increased, not sure the right call, what do you guys think?

Thanks a lot pasko@ for looking at this. My TL;DR thoughts here are:

- I share with you the feeling that there might be some chance to make TRACE_EVENT emit less code. Not sure the problem here is the number of layers though, the compiler does really a good job here, I am truly amazed (see below).

- Not sure it's worth instead trying to deal with the actual strings (the .rodata). From #1 that looks just 170 K and changing that would require redesigning telemetry, traceviewer, slow reports and all the pipelines, which is a quite high cost.

Figuring out some concrete action will require some extra days of work staring at the assembly (volunteers more than welcome. I am really out of bandwidth and just this reply took me a morning :/)

> I poked at a few TRACE_EVENT0 macros with lnsdump, they take about 80 bytes each (for code compiled with -Os), which is a bit large.
OMG that completely mismatches what I was expecting/hoping.
However, spoiler, after looking at the assembly it's the usual perf dilemma: everything looks unreasonably big when you look at the big picture, but when you zoom in all the details make sense and you get death by several cuts.

From a high level, after unwrapping all the macros, a TRACE_EVENT0 should "just":
----
1. Create a static local variable X.
2. If X == 0 (this is the first time we hit this macro)
3.    X := GetCategoryGroupEnabled("catname") 
      # X now points to the long-lived char that stores the enabled flag for the category "catname"
4. create a local ScopedTracer obj("event_name"), which under the hoods does just call
   trace_event_internal::AddTraceEvent("catname", "eventname", getttid(), TimeTicks()::Now())
   # And then, when going out of scope.
5. call ~ScopedTracer()
----

Now let's look at the assembly of real world (arm, official build, gcc, -Os) for

extern "C" void foo() {
  asm volatile("bkpt #0x42");  // These are just markers to find the asm quickly.
  { TRACE_EVENT0("cat", "foo");}
  asm volatile("bkpt #0x42");  // These are just markers to find the asm quickly
}

Here's the annotated assembly:

Dump of assembler code for function foo:
   0x0033df2c <+0>:     push    {r4, r5, r6, lr}
   0x0033df2e <+2>:     sub     sp, #40 ; 0x28
   0x0033df30 <+4>:     bkpt    0x0042
   ; ===========================================================================

   ; This is the static local var
   0x0033df32 <+6>:     ldr     r5, [pc, #84]   ; (0x33df88 <foo+92>)
   0x0033df34 <+8>:     add     r5, pc
   0x0033df36 <+10>:    ldr     r4, [r5, #0]

   ; This initialize the static and call GetCategoryGroupEnabled() on the 1st hit
   0x0033df38 <+12>:    cbnz    r4, 0x33df46 <foo+26>
   0x0033df3a <+14>:    ldr     r0, [pc, #80]   ; (0x33df8c <foo+96>)
   0x0033df3c <+16>:    add     r0, pc
   0x0033df3e <+18>:    bl      0x3e4f88 <base::trace_event::TraceLog::GetCategoryGroupEnabled(char const*)>

   ; This derefs the static var to check if the category is enabled
   0x0033df42 <+22>:    mov     r4, r0
   0x0033df44 <+24>:    str     r0, [r5, #0]
   0x0033df46 <+26>:    movs    r3, #0
   0x0033df48 <+28>:    str     r3, [sp, #20]
   0x0033df4a <+30>:    ldrb    r3, [r4, #0]
   0x0033df4c <+32>:    tst.w   r3, #25
   0x0033df50 <+36>:    beq.n   0x33df7a <foo+78>  ;  -> This earlies out

   ; This is an extremely smart (ICF'd) sequence that groups all the gettid() + 
   ; TimeTicks::Now() and calls AddTraceEvent()
   0x0033df52 <+38>:    ldr     r6, [pc, #60]   ; (0x33df90 <foo+100>)
   0x0033df54 <+40>:    add     r5, sp, #4
   0x0033df56 <+42>:    add     r6, pc
   0x0033df58 <+44>:    mov     r0, r5
   0x0033df5a <+46>:    mov     r1, r4
   0x0033df5c <+48>:    mov     r2, r6
   0x0033df5e <+50>:    bl      0x33ddce <trace_event_internal::AddTraceEvent(char, unsigned char const*, char const*, char const*, unsigned long long, unsigned int, unsigned long long) [clone .constprop.13]>

   ; I admit I am a bit lost here. It seem some kind of epilogue which restores
   ; registers from the stack (for what?).
   0x0033df62 <+54>:    ldmia.w r5, {r0, r1}
   0x0033df66 <+58>:    add     r3, sp, #12
   0x0033df68 <+60>:    stmia.w r3, {r0, r1}
   0x0033df6c <+64>:    add     r3, sp, #40     ; 0x28
   0x0033df6e <+66>:    stmdb   r3, {r0, r1}
   0x0033df72 <+70>:    add     r3, sp, #24
   0x0033df74 <+72>:    str     r4, [sp, #24]
   0x0033df76 <+74>:    str     r6, [sp, #28]
   0x0033df78 <+76>:    str     r3, [sp, #20]
   0x0033df7a <+78>:    add     r0, sp, #20

   ; This is the call to ~ScopedTracer that will backannotate the duration of the
   ; event.
   0x0033df7c <+80>:    bl      0x2dd388 <trace_event_internal::ScopedTracer::~ScopedTracer()>
   ; ===========================================================================
   0x0033df80 <+84>:    bkpt    0x0042
   0x0033df82 <+86>:    add     sp, #40 ; 0x28
   0x0033df84 <+88>:    pop     {r4, r5, r6, pc}
   0x0033df86 <+90>:    nop
   0x0033df88 <+92>:    mlaeq   r11, r12, r1, r10
   0x0033df8c <+96>:                    ; <UNDEFINED> instruction: 0x001b0fb1
   0x0033df90 <+100>:   andseq  sp, r10, r5, asr #5
End of assembler dump.


Some thoughts:
- I think we are still paying something for the fact that static locals are thread safe in c++11. We really don't need them to be thread-safe, as tracing was designed (and was working) back in the days of non-thread-safe locals. (realistically, if there is a race, both threads will end up writing the same value to the static var because the GetCategoryGroupEnabled is idempotent).
- There seems to be quite some boilerplate involved in just checking if the category is enabled([<+22>, <+36>]) but I ran out of time to dig down more.
- Conversely to what I think both of us were expecting, calling AddTraceEvent (i.e. traversing all the layers) is extremely compact. ICF did an amazing job here, by partially grouping calls with the same common arguments and effectively de-inlining the call stack. Just, wow.
- I am really lost at [<+54>,<+78>], also I ran out of time.

nice analysis, Primiano!

looks wrap-able into a single call :)

Agreed on the .rodata being too complicated.

I take back the "- I think we are still paying something for the fact that static locals are thread safe in c++11." after re-looking at the assembly and discussing with pasko.
The static variable is really just a pointer (initialized by default at 0) and the compiler knows that reading/writing a pointer is naturally atomic.
The cost there is purely because the static var involves a relocation, so the initial sequence reads as:

; Load the offset (from <92>, that  mlaeq   r11, r12, r1, r10 is just GDB being silly and treating an offset as in struction) that tells where the static variable has been relocated (This is likely because the distance between this instruciton and .rwdata is too big to fit in the imemdiate) 
<+6>:     ldr     r5, [pc, #84]

; Add the offset to pc. r5 now contains the address of the static variable (which in turn will contain the pointer to the category group enabled)
<8>:     add     r5, pc

; r4 = *r5, r4 now contains the value of the pointer to the cat group enabled.
ldr     r4, [r5, #0]

A small explanation for lines +54....:

trace_event_internal::AddTraceEvent() returns a 64-bit structure (TraceEventHandle). Since this is 32-bit ARM, the function is compiled to take the address of the result as its first parameter (named variable |h| in the INTERNAL_TRACE_EVENT_ADD_SCOPED() definition found in base/trace_event/trace_event.h.

Line +40 computes the location of |h| in the stack (into r5).
Line +44 pass it as the first parameter to the function call (into r0).

Line +54 reads the content of the variable into (r0,r1).
Line +60 copies the content into two other stack locations. This looks like the call to ScopedTracer::Initialize() being inlined by the compiler, but I'm not sure why the value is copied twice.

I can see that INTERNAL_TRACE_EVENT_ADD* call trace_event_internal::AddTraceEvent() with several hardcoded parameters - won't it be beneficial for the code size to call special AddTraceEvent() versions instead?

#define INTERNAL_TRACE_EVENT_ADD_SCOPED(category_group, name, ...)           \
  INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);                    \
  trace_event_internal::ScopedTracer INTERNAL_TRACE_EVENT_UID(tracer);       \
  if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {                       \
    base::trace_event::TraceEventHandle h =                                  \
        trace_event_internal::AddTraceEvent(                                 \
            TRACE_EVENT_PHASE_COMPLETE,                                      \
            INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,          \
            trace_event_internal::kGlobalScope, trace_event_internal::kNoId, \
            TRACE_EVENT_FLAG_NONE, trace_event_internal::kNoId,              \
            ##__VA_ARGS__);                                                  \
    INTERNAL_TRACE_EVENT_UID(tracer).Initialize(                             \
        INTERNAL_TRACE_EVENT_UID(category_group_enabled), name, h);          \
  }

So here we call AddTraceEvent() with several constants: trace_event_internal::kGlobalScope, trace_event_internal::kNoId, TRACE_EVENT_FLAG_NONE, trace_event_internal::kNoId - each takes code to set up. And btw trace_event_internal::kNoId is a 64-bit integer.

What if we had (non-inline) AddTraceEvent_Scoped() that calls AddTraceEventWithThreadIdAndTimestamp() with those constants?

Adding Annie as she cares about tracing a lot these days.

+panzer who may be interested in taking a look

Assigning to myself since jaebaek@ is no longer working on Chrome.

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

commit c5fb30be3e04239045ebe2c64dd80aa6cf046a4e
Author: David 'Digit' Turner <digit@google.com>
Date: Fri Oct 05 14:42:49 2018

base: make ScopedTracer smaller.

Use C++11 default initializers to make ScopedTracer smaller
and simpler. Surprisingly, this saves 12288 bytes in
MonochromePublic.apk for the 32-bit ARM build!

BUG=702718,708990
R=agrieve@chromium.org,lizeb@chromium.org,pasko@chromium.org,alexilin@chromium.org,primiano@chromium.org,picksi@chromium.org

Change-Id: Ia1d3e936ec8b9cfe3c52b9cfc0b97a2a38ac7043
Reviewed-on: https://chromium-review.googlesource.com/c/1254723
Reviewed-by: Benoit L <lizeb@chromium.org>
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Egor Pasko <pasko@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Reviewed-by: Alexandr Ilin <alexilin@chromium.org>
Commit-Queue: David Turner <digit@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597111}
[modify] https://crrev.com/c5fb30be3e04239045ebe2c64dd80aa6cf046a4e/base/trace_event/trace_event.h

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

commit 331266377d03b51dc3e2cf2c26b896e21f8f0391
Author: Alexandr Ilin <alexilin@chromium.org>
Date: Wed Nov 14 14:48:17 2018

Constexpr-eliminate GetCategoryGroupEnabled calls for popular categories

This CL allows to avoid the cost of calling GetCategoryGroupEnabled() in
TRACE_EVENT macros for popular categories, in a way that doesn't require more
macros, nor changing all the call sites.

The idea is to put all popular categories into a static global array so an
address of a category state may be determined at compile-time through a call
to a constexpr function.

This CL makes it impossible to use non constant expressions as a category name
in the tracing macros. All the call sites that don't satisfy this requirement
have to be converted. Hopefully, there aren't a lot of such callers.

This change reduces the code size generated from each trace macro by ~16 bytes,
check the full report here:
https://docs.google.com/document/d/1piIq_yi2fsqOEKObx0tFHeunMyX7hp2ZdAGKK6t0k80/edit?usp=sharing.
The total Android apk size savings are ~60 KiB.

Bug: 702718, 708990
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I9f7b48fd4ee614996feaabda3e5495fd9b786c3a
Reviewed-on: https://chromium-review.googlesource.com/c/1251361
Commit-Queue: Alexandr Ilin <alexilin@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Reviewed-by: vmpstr <vmpstr@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: David Turner <digit@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607975}
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/android_webview/common/devtools_instrumentation.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/BUILD.gn
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/android/early_trace_event_binding.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/android/trace_event_binding.cc
[delete] https://crrev.com/65644ef9859380e742f3a5d91c627e3b3e942183/base/trace_event/auto_open_close_event.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/auto_open_close_event.h
[add] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/builtin_categories.cc
[add] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/builtin_categories.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/category_registry.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/category_registry.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/cpufreq_monitor_android.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/memory_dump_manager.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/memory_dump_manager.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/trace_category.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/trace_category_unittest.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/trace_event.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/trace_event_unittest.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/trace_log.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/base/trace_event/trace_log.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/cc/base/devtools_instrumentation.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/cc/base/devtools_instrumentation.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/cc/benchmarks/benchmark_instrumentation.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/cc/tiles/frame_viewer_instrumentation.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/cc/tiles/frame_viewer_instrumentation.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/chrome/browser/android/vr/gvr_scheduler_delegate.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/chrome/browser/android/vr/scoped_gpu_trace.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/chrome/browser/android/vr/scoped_gpu_trace.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/components/heap_profiling/test_driver.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/content/browser/renderer_host/render_widget_targeter.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/content/browser/tracing/file_tracing_provider_impl.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/media/base/scoped_async_trace.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/media/base/scoped_async_trace.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/media/blink/video_frame_compositor.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/media/blink/video_frame_compositor.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/media/gpu/android/media_codec_video_decoder.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/BUILD.gn
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/base/network_delegate.cc
[delete] https://crrev.com/65644ef9859380e742f3a5d91c627e3b3e942183/net/base/trace_constants.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/base/trace_constants.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/cert/crl_set.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/cert/multi_threaded_cert_verifier.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/dns/host_cache.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/dns/host_resolver_impl.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/http/http_cache_transaction.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/http/http_stream_factory_job.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/log/trace_net_log_observer.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/nqe/network_quality_estimator.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/proxy_resolution/proxy_resolver_v8_tracing.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/quic/quic_stream_factory.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/client_socket_handle.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/client_socket_pool_base.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/socket_posix.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/ssl_client_socket_impl.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/ssl_client_socket_pool.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/transport_client_socket_pool.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/udp_socket_posix.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/socket/websocket_transport_client_socket_pool.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/spdy/spdy_session_pool.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/net/url_request/url_request_http_job.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/services/tracing/public/cpp/perfetto/trace_event_data_source_unittest.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/services/tracing/public/cpp/trace_event_agent_unittest.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/bindings/runtime_call_stats.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/network/network_instrumentation.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/scheduler/common/throttling/cpu_time_budget_pool.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/scheduler/common/tracing_helper.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/scheduler/common/tracing_helper.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/scheduler/common/tracing_helper_unittest.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/scheduler/main_thread/frame_scheduler_impl.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.h
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/ui/gl/gl_surface_egl.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/ui/latency/frame_metrics.cc
[modify] https://crrev.com/331266377d03b51dc3e2cf2c26b896e21f8f0391/ui/latency/latency_info.cc

If I add a new builtin should I always update kMaxCategories +1? Is the same true if I add a comma separated category grouping?

This is related to https://chromium-review.googlesource.com/c/1251361

Anything more that can be done here? Maybe just wait for perfetto and see what it does to binary size?

yeah, we are not actively engaging with tracing macros, given the imminent vicinity of perfetto touches in the same areas. Preferring to keep the bug open for re-evaluating leftovers after perfetto changes. Is there a bug to block this on?