*.mojom-blink.h is huge |
||||||
Issue descriptionChrome Version: ToT OS: All What steps will reproduce the problem? (1) Build chrome locally (2) Take a look at third_party/blink/public/mojom/net/ip_address_space.mojom It's a very simple mojom for a single enum definition. (3) ./tools/include_tracer.py -Iout/Default/gen third_party/blink/public/mojom/net/ip_address_space.mojom-blink.h What is the expected result? include_tracer.py shows some headers, and the last-printed value is small. What happens instead? include_tracer.py shows 350+ headers, and the last-printed value is 2.03MB. Please use labels and text to provide additional information. - This is one of the reasons of slow Blink compilation. ip_address_space.mojom-blink.h was included from a popular header. - If we want to use the type 'IPAddressSpace' in a header file, we can avoid to include the huge ip_address_space.mojom-blink.h by declaring 'enum class IPAddressSpace : int32_t;'. However, it's hard to declare more complex types.
,
Jul 10
,
Jul 10
,
Oct 10
@oksamyt: would you be interested in looking into this?
,
Oct 10
I have commented out all the #include statements except the ones that were necessary for the third_party/blink/public/mojom:mojom_platform_blink target to build. The resulting includes: out/Default/gen/third_party/blink/public/mojom/net/ip_address_space.mojom-blink.h #include "mojo/public/cpp/bindings/mojo_buildflags.h" #if BUILDFLAG(MOJO_TRACE_ENABLED) #include "base/trace_event/trace_event.h" #endif #include "third_party/blink/public/mojom/net/ip_address_space.mojom-shared.h" #include "mojo/public/cpp/bindings/lib/wtf_clone_equals_util.h" out/Default/gen/third_party/blink/public/mojom/net/ip_address_space.mojom-shared.h #include "mojo/public/cpp/bindings/array_data_view.h" #include "third_party/blink/public/mojom/net/ip_address_space.mojom-shared-internal.h" out/Default/gen/third_party/blink/public/mojom/net/ip_address_space.mojom-shared-internal.h all include statements removed Running include_tracer.py now shows '1.71080589294 megabytes of chrome source', which doesn't seem like a great reduction. Before investigating what would be involved in customizing the include list according to the types declared in the module: would this potential improvement make a difference for the blink team? I suspect that for more complex types more headers will need to be included.
,
Oct 10
We could do something coarse for now, like: if any interface/request types are referenced, we include all the standard headers. If not, we can omit the standard mojo headers that get included (this includes the one included transitively through the generated mojom-shared-[internal].h too) just for interface definition / serialization. That would probably still leave us with quite a few headers which are only used for struct serialization code and thus unnecessary when defining only enums. At the same time though, how common is it really to have a mojom file which only defines enums? Most define at least one struct, and in that case we don't have much we can trim.
,
Oct 10
What do you think about generating something like foo.mojom{-blink}.forward.h which will have:
- enum definitions;
- forward declarations of all interfaces and structs;
- declarations of FooPtr, FooRequest and FooPtrInfo.
This should require just basic includes + common mojo includes like interface_ptr.h.
I _think_ this could help with a common issue of including large generated files to headers which just need to reference a generated class/enum/ptr without a real definition.
,
Oct 11
I agree with Comment 7.
,
Oct 16
,
Oct 17
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tkent@chromium.org
, Jul 10