Build time can be an issue. By default, the build system uses three simple controls to try and maximize build efficiency:
These three variables all scale to the number of processor cores available on the build system. 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.
If you need to achieve even faster builds than what the build system produces by default, you can consider and implement some of the following:
BB_NUMBER_THREADS
,
BB_NUMBER_PARSE_THREADS
, and
PARALLEL_MAKE
:
As previously mentioned, the build system scales the values
for these variables.
However, you can manually override them in your
local.conf
file if you are not satisfied
with the defaults.
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 /tmp
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
Build Directory
contents could easily be rebuilt.
Inheriting the
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
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:
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
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}"
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.