Searched hist:"0 ad63df8aa8ab60f74395794d8ffce64c82ee031" (Results 1 – 1 of 1) sorted by relevance
| /openbmc/bmcweb/ |
| H A D | meson.build | diff 42bbcd87d4813c6f01497ced4418d4a6f4e64c3f Sat Jan 07 20:04:28 CST 2023 Ed Tanous <edtanous@google.com> Use intermediate bmcweb object files
If you look at an OpenBMC build, every source file is compiled for every
source unit. This is pretty wasteful, but meson documents how to reuse
object files between link units. This has a couple benefits:
- Source files are only compiled once
- There are less likely to be unit-test specific binary differences (if,
for example, the unit tests used different compiler flags).
- Errors in a source file only appear once in the output, instead of 10
times.
On my 36 core Xeon, a normal build went from 2m38s down to 2m34s, which
is quite underwhelming, and less than you'd expect from a change this
large, but it turns out that if you have more parallelism than you have
compile units, building things twice doesn't appear to matter much.
With that said, if I simulate a smaller machine, using -J 8, the build
time with this commit remains at 2m38s, whereas the commit previous to
this takes 4m48s, so clearly there's some benefit here.
This regression appears to have been caused by
0ad63df8aa8ab60f74395794d8ffce64c82ee031 which caused us to build
multiple executables (one per unit test). This fixes the regression.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Ib77e8679b69e0f2242f65c20b129f2fb8e370edb
diff 0ad63df8aa8ab60f74395794d8ffce64c82ee031 Mon Oct 17 18:03:21 CDT 2022 Nan Zhou <nanzhoumails@gmail.com> use multiple test targets
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57648/8 is unfortunately
rejected by some CI issues where # lines covered by unit test is not
consistent.
Thus, this commit is written to bypass subdir, but still addes the
ability to run a test for a specific component. This speeds up iteration
when developers are working on a subset of the project.
For example, we can compile and run the query_param_test separately. The
speed up will be more obvious when we have better solution to deal with
the current headers and inline functions in the future.
```
meson test query_param_test -C b
ninja: Entering directory `/usr/local/google/home/nanzhou/Desktop/bmcweb/b'
ninja: no work to do.
1/1 query_param_test OK 0.01s
Ok: 1
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0
```
The compile time increases a little bit. This doesn't matter too much
given tests are disabled in Yocto builds.
```
[hi on] nanzhou@nanzhou:~/Desktop/bmcweb$ time ninja test -C b
ninja: Entering directory `b'
[49/50] Running all tests.
1/1 bmcweb_unit_test OK 0.07s
Ok: 1
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to /usr/local/google/home/nanzhou/Desktop/bmcweb/b/meson-logs/testlog.txt
real 1m56.361s
user 12m11.587s
sys 1m15.924s
[hi on] nanzhou@nanzhou:~/Desktop/bmcweb$ time ninja test -C b
ninja: Entering directory `b'
[247/248] Running all tests.
1/23 crow_getroutes_test OK 0.34s
2/23 router_test OK 0.31s
3/23 utility_test OK 0.29s
4/23 dbus_utility_test OK 0.28s
5/23 google_service_root_test OK 0.27s
6/23 http_utility_test OK 0.26s
7/23 human_sort_test OK 0.24s
8/23 multipart_test OK 0.21s
9/23 openbmc_dbus_rest_test OK 0.20s
10/23 privileges_test OK 0.18s
11/23 registries_test OK 0.17s
12/23 hex_utils_test OK 0.16s
13/23 ip_utils_test OK 0.15s
14/23 json_utils_test OK 0.15s
15/23 query_param_test OK 0.13s
16/23 stl_utils_test OK 0.12s
17/23 chassis_test OK 0.10s
18/23 service_root_test OK 0.04s
19/23 thermal_subsystem_test OK 0.03s
20/23 configfile_test OK 0.23s
21/23 lock_test OK 0.22s
22/23 time_utils_test OK 0.11s
23/23 log_services_dump_test OK 0.07s
Ok: 23
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to /usr/local/google/home/nanzhou/Desktop/bmcweb/b/meson-logs/testlog.txt
real 2m8.792s
user 29m15.844s
sys 3m10.264s
```
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Change-Id: I6f763173c1e7de96ab757673fb5ed0a73e4532f5
|