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