Yesterday I found very interesting maillist - kde-optimize@mail.kde.org . There is some kde perfomance tips. One of these tips: compile kde with --enable-final configure option increase perfomance (a little) and compile faster. I think it should be used in future kde ebuilds
this was enabled until 7 weeks ago, http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/eclass/kde-functions.eclass?rev=1.48&content-type=text/vnd.viewcvs-markup quote from the gentoo-dev mail: Anyone who still wants it for whatever reason can simlpy export myconf="--enable-final" in their shell or make.conf. $myconf is passed to configure by all kde ebuilds. how much faster compiles kde? how much faster is the compiled source?
Two quotes from the ml: -- http://lists.kde.org/?l=kde-optimize&m=104256024417094&w=4 On my old K6/200 --enable-final was the only way to get KDE compiled without waiting for days. ---- -- http://lists.kde.org/?l=kde-optimize&m=104249967417182&w=4 > > > No, it takes _alot_ longer to compile, but might give minor speed-ups. > > > That's why it is default off. > > > > No, it's about 2x faster to compile, of course, you can't do incremental > > compliation. > > On your machine? Interesting... Computationally it is more demanding, but > it issues fewer IO calls (although it accesses the same amount of data) Why do you think it'd be more computationally demanding? Each header file is compiled exactly one with --enable-final, and not dozens upon dozens of times. And I don't think gcc's inliner is active enough to pull in much stuff from the non-inline methods. Hmm, I haven't compared this much with gcc-3.2, though. ---- I didn't check this flag so I can't add anything
Well, to sum things up... Benefits of enable-final: - compile can be several times quicker if you enough ram, especially in e.g. koffice. - produced executable can in theory be a little faster, but this efect has never been measured and is probably negligible. Problems with enable-final: - needs a _LOT_ of ram (as in, easily 200mb ram for the bigger libraries, 300mb+ in extreme cases). If you don't have it it starts swapping out and you lose any benefit in compile speed. - makes ccache practically useless as any small change requires resomcpiling the whole binary/library. - is known to break compilation once in a while even in kde-base. So we had to go around marking packages ok or not ok for enable-final all the time when we had it. - is said by Dirk Mueller et al to be slightly dangerous. Quote a thread from kde-packager: Dirk: In any way its better to create packages by not using enable-final as its not really well tested. Me: You seem to be suggesting there may be runtime problems introduced by using enable-final, even when things compile ok. Is that so? We haven't had any such problems in Gentoo... <snip> Dirk: You can't trust it. We had this case already once. "static" variables change their scope when you compile final. this can cause very subtile bugs in (of course badly coded) applications. Me: Hm... But, isn't this a beta (alpha?) option we should continue testing and fixing problems, or should we just forget about it? Stephan Kulow: If you find problems with it, feel free to report or/and fix it. But you need to be aware that you're running your own risk here. But as almost any distribution uses this flag, I wouldn't be too paranoid about it :) -- So, you can judge for yourself. For now it stays off. Add it to $myconf if you feel like it. You can even submit a bugreport to bugs.kde.org if it breaks something.
*** Bug 21151 has been marked as a duplicate of this bug. ***
I think that given the poor performance of GCC 3.2 while compiling C++ applications and my experience using the KDE ports under FreeBSD, --enable-final should be reintroduced. My Athlon 1.2 needn't take days to build KDE. If heavy swapping is really an issue, a lowmem USE flag could be used to disable the option. Thoughts?
The biggest problem with this is that the kde folks themselves claim to NOT support --enable-final. Sometimes it may work, sometimes not. I'm not against using it, but a problem we may run into is that minor upgrades, like 3.1.1 to 3.1.2 may break because of its usage. Also, it may break on various architectures due to different .h files and what they contain inside.
On ppc machines the performance gain is incredible. I would like to use this feature for the ppc livecds, therefore I'd like to make this behaviour triggerable by a use flag. for grp builds this use flag can easily be not enabled, but for kde ppc livecds it can make a huge difference I believe. A use flag is easier to switch on/off than exporting myconf. especially when building livecds. (I tend to only look at the IUSE="") I have cc'ed livewire on this, I believe his opinion (since he maintains the kde x86 livecd is valueable too) Pieter
I was told the same thing from kde devs that --enable-final usually breaks things.. This was my experience, everything compiled fine without it. But a USE flag would probaly be fine, as long as its not default. Bob
I wouldn't say that it usually breaks things, it's just that it may or may not work (I don't think it's tested prior to packaging). But yes, a USE flag should be okay.
if you set myconf="--enable-final" and emerge kde on a fresh stage3 install, the process fails during configure phase of qt because enable-final is an unknown option to qt. No enable-final enabled kde livecd for now :-)
The solution to that is not to set --enable-final in $myconf until building the kde ebuilds themselves
Here is a small patch for eclass/kde.eclass: --- schnipp --- /var/portage/eclass/kde.eclass 2003-09-30 21:08:09.000000000 +0200 +++ /mnt/gentoo/var/overportage/eclass/kde.eclass 2003-10-04 07:24:22.000000000 +0200 @@ -27,6 +27,10 @@ # overridden in other places like kde-dist, kde-source and some individual ebuilds SLOT="0" +kde_disable_final() { + export kde_disablefinalflag=1 +} + kde_src_unpack() { debug-print-function $FUNCNAME $* @@ -87,6 +91,15 @@ else myconf="$myconf --disable-debug --without-debug" fi + if [ `use kdefinal` ]; then + if [ "$kde_disablefinalflag" ]; then + einfo "disable final" + else + einfo "enable final" + myconf="$myconf --enable-final" + fi + + fi debug-print "$FUNCNAME: myconf: set to ${myconf}" ;; configure) --- schnapp --enable-final now can be set with the "kdefinal" USE flag and can be deactivated in the ebuild (if it's breaks compilation like e.g. in kportage) with the kde_disable_final() function.
hi, i tested enable-final and the most obvious benefit is the decreased compile-time of kdepackages. genlop tells me that usually kdelibs takes about 2h 10minutes on my machine. but when using --enable-final i needed 53mins kdebase (no enable-final) ~2h 30mins kdebase --enable-final 1h 39mins kdenetwork ~1h kdenetwork --enable-final 26min i didn't yet experience any problems with --enable-final, testing since sep 23th!
I compile kde with --enable-final. Compilation is about twice faster (256MB RAM) and it works without a problem since 26 september so I agree with last posts - this should be controlled by use flag and should be disabled by default.
REOPENED... and now?
I think we should NOT enable final when we use distcc http://distcc.samba.org/faq.html#enable-final
Re: #16: well, as long as we're talking about things that aren't enabled by default, unsermake should allow you to take full advantage of enable-final _and_ distcc. Briefly, one of the things it does is make the makefiles non-recursive, i.e. instead of make going into each subdir (and there compiling the single enable-final-generated .cpp), you can parallelize make over all the subdirs at once with a single top-level makefile containing all of the targets. --- As for an off by default use flag: I don't particularly like the idea, because I fear we'll just have another unsupported configuration, and will end up telling people to recompile the slow way whenever they submit a bug report about runtime misbehaviour we can't figure out. IMHO, anything that potentially creates subtly bad binaries during compilation is to be avoided like the plague. But if everyone else thinks it's OK, fine, we'll just have to mark it prominently as problematic/unsupported. Or does anyone believe it's gotten more stable lately?
well myconf="--enable-final" emerge kde kde-i18n works perfect for me. But this way, you have the problem to emerge all dependencies first. An USE-flag "final" would be really nice!
Two years have passed... I asked on kde-packager for uptodate opinion and Stephan Kulow answered: "Dirk is right, it's not as well tested as --disable-final and we once had a subtle bug. Now it depends on how paranoid you are - SUSE didn't had a problem report so far that was fixed by recompiling with --disabled-final. We never tried though ;)" Sounds safe enough to play with - carefully - so I'd like to add a use flag, off by default, for the 3.4 release... and see what happens. If we get bugreports that are fixed by disabling it, it'll go away again. As usual, object in time or I'll do it.
great deal.
I'm committing this to kde.eclass. It uses a new global USE flag called kdeenablefinal. Note that this is on a purely worksforme basis, even though it affects stable-keyworded ebuilds, so be careful for now. The USE flag is of course off by default.
Ah yes, and it only affects KDEBASE packages for now, since 3rd party source might conceivably have lower coding standards or something.
