Performance

Performance is an essential point for measuring the quality of a build system.
We are continously improving poky/bitbake performance, including major parts of build time, disk footprint, and file parsing speed.
Here are some performance measurement results: (b22e345e05efcc3f66278af8f09fb083afe32b68 is chosen as "Current" commit)

Table 1: File Parsing Time Optmization Results

File parsing time	Green-3.3.1	Yocto-0.9	Optimization A	Optimization B	Current
BB file number	925	844	757	757	769
time (s)	17	45	29	26	16

Note:
Optimization A: Exclude variables in distro_tracking_fields.inc from normal parsing. (In master tree, commit: 53aff7d6775eb1c2c8f419f325b91c062d85eed5)
Optimization B: "??=" re-implementation. (Pending for review)
Current: Latest master with parallel parsing mechanism

Table 2: Build Time Optmization Results (poky-image-minimal)

Build time	Green-3.3.1	Yocto-0.9	Exec (before pseudo wrapper)	Fork (after pseudo wrapper)	Current
Recipe number	88	147	147	147	147
time (s)	32m57s	88m50s	114m6s	99m52s	134m39s

Note:
Using fork way in bitbake will gain about 10% build time for poky-image-minimal.
The current build time is somewhat long, which we will look at.

Table 3: Disk Footprint Optmization Results (poky-image-minimal)

Disk Space	Green-3.3.1	Yocto-0.9	Optimization A	Optimization B	Current
Recipe number	88	147	147	147	147
Disk size (GB)	7.6	29	24	19	24

Note:
Optimization A: Remove the temp files in sstate-build-* (In master tree, commit: 7e7bb24b8512dd1452a11d8aeafc8dedcbc4d623).
Optimization B: Using hardlink to replace copy between "package-->packages-split", "image-->sysroot-destdir", and "sysroot-destdir-->/tmp/sysroots" (Pending for review).

There are some other data we may add later.
1) Using socket data accessing approach to avoid data re-parsing when fork/exec new bitbake processes.