Drafted a CL here: https://chromium-review.googlesource.com/#/c/chromium/src/+/812104

It'll emit the following trace events:

{{proxy_name}}::{{method.name}}
{{class_name}}_{{method.name}}_ForwardToCallback
{{class_name}}_{{method.name}}_ProxyToResponder
{{class_name}}_{{method.name}}_HandleSyncResponse
{{class_name}}StubDispatch:{{method.name}}
{{class_name}}StubDispatch:{{method.name}}
{{class_name}}RequestValidator:{{method.name}}
{{class_name}}ResponseValidator:{{method.name}}

This is better than before from functional perspective, but looks ugly. Can you help me renaming some of these to indicate concepts they implement? I.e. there should be a thing that calls service implementation after deserializing arguments, is it Dispatch? What is ForwardToCallback?

Sure:

{{proxy_name}}::{{method.name}} is serializing a message and writing it into the pipe.

ForwardToCallback is deserializing and dispatching a received response back to the caller. Used for messages that expect responses.

ProxyToResponder is serializing a response from an implementation and writing it into the pipe. Used for messages that expect responses.

HandleSyncResponse is similar to ForwardToCallback (deserializing a received response) except there's no dispatch step because the bindings will internally block until they receive a response, at which point HandleSyncResponse does the deserialization and updating of output args before returning.

StubDispatch is deserializing and dispatching a received message to an implementation.

RequestValidator and ResponseValidator are just part of the deserialization paths above.

Thanks! Naming is hard, but in the end I came up with something coherent, I think:

1. {{namespace_as_string}}::{{class_name}}::{{method.name}} for client methods.

2. (Service){{namespace_as_string}}::{{class_name}}::{{method.name}} for corresponding service methods.

3. {{namespace_as_string}}::{{class_name}}::{{method.name}}Callback for client callbacks (ForwardToCallback).

4. (Service){{namespace_as_string}}::{{class_name}}::{{method.name}}Callback for service-side callbacks (ProxyToResponder).

I've removed HandleSyncResponse because it's contained in the corresponding client method trace, and RequestValidator / ResponseValidator because they are following / followed by other mojom traces.

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

commit 652d384e82c17d8a420009fa95c804bd91eb4be6
Author: Dmitry Skiba <dskiba@chromium.org>
Date: Wed Dec 13 00:29:32 2017

Improve mojo method tracing.

This CL refines TRACE_EVENTs added to generated mojo code:

1. "ns::Class::Method" event is emitted when client calls a mojo interface.

2. "(Impl)ns::Class::Method" event is emitted when mojo calls the
   implementation of an interface.

3. "(Impl)ns::Class::MethodCallback" event is emitted when an implementation
   calls the method's callback.

4. "ns::Class::MethodCallback" event is emitted for async methods when
   the method's callback is called on the client side.

Additionally, this CL removes couple of redundant TRACE_EVENTs that are
either contained in the events above, or are not useful for understanding
mojo call flow.

Bug:  792614 
Change-Id: I03ac80729ff0e9d0c4ad9fb7fc98e962110a0518
Reviewed-on: https://chromium-review.googlesource.com/812104
Reviewed-by: Ken Rockot <rockot@chromium.org>
Commit-Queue: Dmitry Skiba <dskiba@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523621}
[modify] https://crrev.com/652d384e82c17d8a420009fa95c804bd91eb4be6/mojo/public/cpp/bindings/lib/connector.cc
[modify] https://crrev.com/652d384e82c17d8a420009fa95c804bd91eb4be6/mojo/public/tools/bindings/generators/cpp_templates/interface_definition.tmpl