Mart Raudsepp posted on Thu, 30 Aug 2012 07:27:48 +0300 as excerpted: > Geode LX700 (433MHz) with 256MB RAM MAKEOPTS=-j2 (single core system) > gcc (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2 > > ebuild prepare done before as well. > > 1. time ebuild foo configure — real time value > 2. time ebuild foo compile — real time value > > ver (1) (2) (1+2) > udev-171-r6: 47.2s / 4m36.4 / 5m23.6 > udev-188 : 69.6s / 6m27.2 / 7m36.8
Thanks. Those are the data-points of an older udev and a current "semi- integrated" udev that gentoo has "deintegrated" to a point. Now, for worst-case comparison, on the same machine, what's the respective times for a full systemd build? (I'm not saying actually merge it, just configure/compile, plus see the next paragraph.) Also, note that ebuild foo install only does the install to the fake location in PORTAGE_TMPDIR. It's the ebuild qmerge step that actually merges to the live filesystem. So the install phase should be safe to try without actually merging as well, just don't qmerge. And on some packages the install phase actually does enough additional work to be worth timing as well. I don't know if that's the case here or not, but it's probably worth testing, just in case. So far, the results are encouraging. Higher times, but not THAT much higher, with the new version. But if the worst happens and we really DO end up building all of systemd and then throwing most of it away, what's the relative times for THAT? That's actually what I was asking earlier, and this gets us part way to the answers, but not all the way. Regardless, thanks, this is considerably more solid information than was available earlier, and not everyone has a geode to actually do the test on, so these numbers are a real contribution to the available information, indeed! =:^) (Now I'm wondering just how low I could clock this bulldozer, and whether setting uniprocessor kernel command-line-option and downclocking as far as possible, plus memory-limiting to say 256MB for my own tests is worth the trouble. FWIW I also have an original atom netbook that's slow enough to be interesting, but I do my builds for it in a 32-bit chroot on the main machine then rsync them over, and I've not actually updated the netbook in over a year, so I'd have to do a seriously major update, then figure out how to make the portage tree available on the netbook, to test that, and that's DEFINITELY more work than I'm likely to put into such a test, near-term anyway, so deliberately crippling the bulldozer is about the best I'll get. But that'd make for an interesting comparison against normal performance on this hardware, as well, so I just might do that one of these days if I get the urge to do some fiddling.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
