Changes between Version 1 and Version 2 of AnalyzingBuildPerformance

Timestamp:

Oct 7, 2021, 12:14:30 PM (3 years ago)

Author:

jer.noble@apple.com

Comment:

--

AnalyzingBuildPerformance

@@ -18 +18 @@
 == Building WebKit with tracing enabled ==
 
-1. Clean your build directory (but make sure it still _exists_).
+1. Clean your build directory (but make sure it still ''exists'').
 2. `ClangBuildAnalyzer --start path/to/WebKitBuild`
 3. `make debug ARGS='OTHER_CFLAGS=-ftime-trace OTHER_CPLUSPLUSFLAGS=-ftime-trace' `
@@ -46 +46 @@
 From this we can see that JSDOMGlobalObject.h is a very expensive header; it contributes about 3.3s of compile time, on average, to every source file which includes it. And it is included 246 times, which given the WebKit unified build system, means it is included by a majority of source files in the WebCore project. For these expensive headers, its often the case that the "expensive" header is expensive due to including other expensive headers, and one approach to make that header less expensive is to forward declare types rather than include their definitions. In cases where inline implementations of methods make forward declaration impossible, those inline definitions can be moved into a `<Type>Inlines.h` file, and the original declarations annotated with `inline`. Source files which contain references to those inline functions must include the `<Type>Inlines.h` file, or the compile will generate a `-Wundefined-inline` error.
 
+=== Header Best Practices ===
+
+While resolving some expensive headers, a few best practices stood out to reduce compilation times without regressing runtime performance:
+
+==== Forward-declare all the things ====
+
+Forward-declaring types used by your class's methods allows clients who don't call those methods to not incur the compile-time cost of including those types' headers.
+
+C++ class members must be fully defined, so e.g. consider using `UniqueRef<MyClass>`, and forward-declaring `MyClass`, instead of including `MyClass.h`.
+
+C++ function parameters and return values do not need to be fully defined, and can be forward-declared. So e.g. if `MyClass` function parameter or return value, consider forward-declaring `MyClass`, instead of including `MyClass.h`.
+
+C++ virtual functions are rarely able to be inlined, even if decorated with `inline`, so avoid inline definitions of virtual functions. So e.g. if defining a virtual base class method that returns a `Ref<MyClass>`, put the default implementation inside the class implementation file.
+
+==== Avoid class-scoped enums ====
+
+When defining a public enumeration for a class, do so at namespace scope rather than inside the class, and always specify an explicit enum size. E.g.:
+
+Bad:
+{{{
+#!c++
+// MyClass.h
+class MyClass {
+public:
+    enum Options {
+        Option1,
+        Option2,
+        Option3,
+    };
+...
+};
+}}}
+
+Good:
+{{{
+#!c++
+// MyClass.h
+enum class MyClassOptions : uint8_t {
+    Option1,
+    Option2,
+    Option3,
+};
+class MyClass {
+public:
+...
+};
+}}}
+
+This allows clients to forward declare the enum type, rather than include `MyClass.h`:
+{{{
+#!c++
+// YourClass.h
+enum class MyClassOptions : uint8_t;
+class YourClass {
+    void functionWithMyClassOptions(MyClassOptions);
+};
+}}}
+
+==== Add Inlines.h headers ====
+
+When explicitly inlining a function definition for performance reasons, and that definition requires including an external header, putting the inline definition in an Inlines.h header file. Annotate the class method declaration with `inline`, which will cause a compiler warning if the Inline.h header is not included by the caller. E.g.:
+
+Bad:
+{{{
+#!c++
+// MyClass.h
+#include "YourClass.h"
+class MyClass {
+public:
+    YourClass& yourClassGetFoo() { return YourClass::foo(); }
+};
+}}}
+
+Good:
+{{{
+#!c++
+// MyClass.h
+class MyClass {
+public:
+    inline YourClass& yourClassGetFoo();
+};
+
+// MyClassInlines.h
+inline YourClass& MyClass::yourClassGetFoo() { return YourClass::foo(); }
+}}}