diff options
Diffstat (limited to 'documentation/dev-manual/speeding-up-build.rst')
-rw-r--r-- | documentation/dev-manual/speeding-up-build.rst | 109 |
1 files changed, 109 insertions, 0 deletions
diff --git a/documentation/dev-manual/speeding-up-build.rst b/documentation/dev-manual/speeding-up-build.rst new file mode 100644 index 0000000000..6e0d7873ac --- /dev/null +++ b/documentation/dev-manual/speeding-up-build.rst | |||
@@ -0,0 +1,109 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
2 | |||
3 | Speeding Up a Build | ||
4 | ******************* | ||
5 | |||
6 | Build time can be an issue. By default, the build system uses simple | ||
7 | controls to try and maximize build efficiency. In general, the default | ||
8 | settings for all the following variables result in the most efficient | ||
9 | build times when dealing with single socket systems (i.e. a single CPU). | ||
10 | If you have multiple CPUs, you might try increasing the default values | ||
11 | to gain more speed. See the descriptions in the glossary for each | ||
12 | variable for more information: | ||
13 | |||
14 | - :term:`BB_NUMBER_THREADS`: | ||
15 | The maximum number of threads BitBake simultaneously executes. | ||
16 | |||
17 | - :term:`BB_NUMBER_PARSE_THREADS`: | ||
18 | The number of threads BitBake uses during parsing. | ||
19 | |||
20 | - :term:`PARALLEL_MAKE`: Extra | ||
21 | options passed to the ``make`` command during the | ||
22 | :ref:`ref-tasks-compile` task in | ||
23 | order to specify parallel compilation on the local build host. | ||
24 | |||
25 | - :term:`PARALLEL_MAKEINST`: | ||
26 | Extra options passed to the ``make`` command during the | ||
27 | :ref:`ref-tasks-install` task in | ||
28 | order to specify parallel installation on the local build host. | ||
29 | |||
30 | As mentioned, these variables all scale to the number of processor cores | ||
31 | available on the build system. For single socket systems, this | ||
32 | auto-scaling ensures that the build system fundamentally takes advantage | ||
33 | of potential parallel operations during the build based on the build | ||
34 | machine's capabilities. | ||
35 | |||
36 | Additional factors that can affect build speed are: | ||
37 | |||
38 | - File system type: The file system type that the build is being | ||
39 | performed on can also influence performance. Using ``ext4`` is | ||
40 | recommended as compared to ``ext2`` and ``ext3`` due to ``ext4`` | ||
41 | improved features such as extents. | ||
42 | |||
43 | - Disabling the updating of access time using ``noatime``: The | ||
44 | ``noatime`` mount option prevents the build system from updating file | ||
45 | and directory access times. | ||
46 | |||
47 | - Setting a longer commit: Using the "commit=" mount option increases | ||
48 | the interval in seconds between disk cache writes. Changing this | ||
49 | interval from the five second default to something longer increases | ||
50 | the risk of data loss but decreases the need to write to the disk, | ||
51 | thus increasing the build performance. | ||
52 | |||
53 | - Choosing the packaging backend: Of the available packaging backends, | ||
54 | IPK is the fastest. Additionally, selecting a singular packaging | ||
55 | backend also helps. | ||
56 | |||
57 | - Using ``tmpfs`` for :term:`TMPDIR` | ||
58 | as a temporary file system: While this can help speed up the build, | ||
59 | the benefits are limited due to the compiler using ``-pipe``. The | ||
60 | build system goes to some lengths to avoid ``sync()`` calls into the | ||
61 | file system on the principle that if there was a significant failure, | ||
62 | the :term:`Build Directory` contents could easily be rebuilt. | ||
63 | |||
64 | - Inheriting the :ref:`ref-classes-rm-work` class: | ||
65 | Inheriting this class has shown to speed up builds due to | ||
66 | significantly lower amounts of data stored in the data cache as well | ||
67 | as on disk. Inheriting this class also makes cleanup of | ||
68 | :term:`TMPDIR` faster, at the | ||
69 | expense of being easily able to dive into the source code. File | ||
70 | system maintainers have recommended that the fastest way to clean up | ||
71 | large numbers of files is to reformat partitions rather than delete | ||
72 | files due to the linear nature of partitions. This, of course, | ||
73 | assumes you structure the disk partitions and file systems in a way | ||
74 | that this is practical. | ||
75 | |||
76 | Aside from the previous list, you should keep some trade offs in mind | ||
77 | that can help you speed up the build: | ||
78 | |||
79 | - Remove items from | ||
80 | :term:`DISTRO_FEATURES` | ||
81 | that you might not need. | ||
82 | |||
83 | - Exclude debug symbols and other debug information: If you do not need | ||
84 | these symbols and other debug information, disabling the ``*-dbg`` | ||
85 | package generation can speed up the build. You can disable this | ||
86 | generation by setting the | ||
87 | :term:`INHIBIT_PACKAGE_DEBUG_SPLIT` | ||
88 | variable to "1". | ||
89 | |||
90 | - Disable static library generation for recipes derived from | ||
91 | ``autoconf`` or ``libtool``: Here is an example showing how to | ||
92 | disable static libraries and still provide an override to handle | ||
93 | exceptions:: | ||
94 | |||
95 | STATICLIBCONF = "--disable-static" | ||
96 | STATICLIBCONF:sqlite3-native = "" | ||
97 | EXTRA_OECONF += "${STATICLIBCONF}" | ||
98 | |||
99 | .. note:: | ||
100 | |||
101 | - Some recipes need static libraries in order to work correctly | ||
102 | (e.g. ``pseudo-native`` needs ``sqlite3-native``). Overrides, | ||
103 | as in the previous example, account for these kinds of | ||
104 | exceptions. | ||
105 | |||
106 | - Some packages have packaging code that assumes the presence of | ||
107 | the static libraries. If so, you might need to exclude them as | ||
108 | well. | ||
109 | |||