On Tue, 2013-11-12 at 15:31 +0000, Richard Purdie wrote: > I also totalled the time in each task type, the output is below. The > numbers there are interesting as the strip patch seems to add 100s to > do_populate_sysroot. There doesn't seem to be a big difference in > compile time.
That's probably to be expected: the amount of disk bandwidth you save by not copying the symbols into the sysroot (and into sstate) is almost certainly going to be outweighed by the time it takes to strip the files in the first place. So that set of numbers at least does seem believable. In theory at least, adding -Wl,-s to BUILD_LDFLAGS could give you the stripping behaviour at lower cost since the linker could avoid writing out the symbol table in the first place. But I'm not entirely sure how this option is actually implemented within the linker (or whether ld.bfd and ld.gold do the same thing in that respect) and it's entirely possible that it might be no better in practice. Using -march=native for natives is an interesting idea, though even if this was a win on a single machine it might obviously be a net loss in the presence of a shared sstate cache. Of course, the vast majority of -native binaries are run so seldom that their impact on the overall build performance is going to be negligible: the ones that dominate are going to be the toolchain. One idea that I've seen suggested from time to time (but never actually tried out) is that it might be a win under some circumstances to do a 2-stage bootstrap of gcc-native and then use that gcc-native to build gcc-cross as well as all other native packages. If you were building everything from scratch every time then it's hard to imagine this being a real benefit unless your distribution bundled compiler was spectacularly rubbish, but if you assume that these gccs will come out of sstate for most builds then it starts to seem more plausible that this might be worth doing. p. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
