From a9bdc538e6425b79fb0b64550a6fce372ab9ada4 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 16 May 2018 15:07:08 -0700 Subject: dev-manual: Moved "Speeding Up the Build" and renamed it. Renamed to "Speeding Up a Build" and moved out of the setting up chapter to the common tasks chapter. Fixed a couple links in the ref-manual. (From yocto-docs rev: c53fddd353230c8ef1abc21c7a2d2b1f492f034a) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-start.xml | 160 -------------------------- 1 file changed, 160 deletions(-) (limited to 'documentation/dev-manual/dev-manual-start.xml') diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml index 201cbe7340..d8726b4857 100644 --- a/documentation/dev-manual/dev-manual-start.xml +++ b/documentation/dev-manual/dev-manual-start.xml @@ -1080,166 +1080,6 @@ -
- Speeding Up the 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: - - - BB_NUMBER_THREADS: - The maximum number of threads BitBake simultaneously executes. - - - BB_NUMBER_PARSE_THREADS: - The number of threads BitBake uses during parsing. - - - PARALLEL_MAKE: - Extra options passed to the make command - during the - do_compile - task in order to specify parallel compilation on the - local build host. - - - PARALLEL_MAKEINST: - Extra options passed to the make command - during the - do_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 - 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 - 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: - - - Remove items from - 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 - 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}" - - Notes - - - 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. - - - - - - -