1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3Speeding Up a Build
4*******************
5
6Build time can be an issue. By default, the build system uses simple
7controls to try and maximize build efficiency. In general, the default
8settings for all the following variables result in the most efficient
9build times when dealing with single socket systems (i.e. a single CPU).
10If you have multiple CPUs, you might try increasing the default values
11to gain more speed. See the descriptions in the glossary for each
12variable 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
30As mentioned, these variables all scale to the number of processor cores
31available on the build system. For single socket systems, this
32auto-scaling ensures that the build system fundamentally takes advantage
33of potential parallel operations during the build based on the build
34machine's capabilities.
35
36Additional 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
76Aside from the previous list, you should keep some trade offs in mind
77that 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
110