View previous topic :: View next topic |
Author |
Message |
supermihi Guru
![Guru Guru](/images/ranks/rank_rect_3.gif)
![](images/avatars/gallery/Quake3/quake3_uriel.gif)
Joined: 09 Feb 2005 Posts: 348
|
Posted: Sun May 28, 2006 7:58 am Post subject: kdeenablefinal - when does it make sense? |
|
|
Hi,
I am currently compiling KDE on a 800MHz Duron ith 256MB RAM. Nobody is working on that machine, so I wonder if it made sense to enable the "kdeenablefinal" USE-Flag for the emerge. Or is this only recommendable with more RAM? _________________ "You may say I'm a dreamer, but I'm not the only one." |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
lonex Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
Joined: 22 Aug 2004 Posts: 107 Location: Karlsruhe, Germany
|
Posted: Sun May 28, 2006 9:53 am Post subject: |
|
|
kdeenablefinal only makes sense when you have at the very least 512mb ram. even then, it sometimes starts to swap like mad, so i strongly advise against using it with only 256mb of ram. _________________ There are no dumb questions, just dumb answers. So please help users that are new to linux/gentoo by answering unanswered questions. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
lost+found Guru
![Guru Guru](/images/ranks/rank_rect_3.gif)
![](images/avatars/143288637951bc9a93074e6.gif)
Joined: 15 Nov 2004 Posts: 509 Location: North~Sea~Coa~s~~t~~~
|
Posted: Mon May 29, 2006 5:27 am Post subject: |
|
|
Quote: | /usr/portage/profiles/use.desc:
kdeenablefinal - Makes kde ebuilds use the enable-final flag, yielding big compilation speedups at the cost of very heavy mem usage | Quote: | kdeaddons-3.5.0.tar.bz2, configure:
--enable-final build size optimized apps (experimental - needs lots of memory) |
...but, at the cost of what else? Does it need more RAM at compile time only, or at runtime too?
Building "size optimized apps" looks like using -Os to me. :-S
Cheeeers. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
supermihi Guru
![Guru Guru](/images/ranks/rank_rect_3.gif)
![](images/avatars/gallery/Quake3/quake3_uriel.gif)
Joined: 09 Feb 2005 Posts: 348
|
Posted: Mon May 29, 2006 5:51 am Post subject: |
|
|
afaik it needs a lot of memory during compile time at the cost that you'r almost not able to use your compuer while it compiles. It loads the whole package into memory and compiles it as once, instead of linking the various programs together.
By doing this it is also possible to create more efficient, smaller binaries. So, if you have enough mem, you should really enable this flag.
This is what I heard, but currect me if I'm wrong. _________________ "You may say I'm a dreamer, but I'm not the only one." |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hum Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
Joined: 13 Oct 2005 Posts: 116 Location: Canada
|
Posted: Mon May 29, 2006 6:03 am Post subject: |
|
|
Quote: | --enable-final:
Concatenates all .cpp files into one big .all_cpp.cpp file, and compiles it in one go, instead of compiling each .cpp file on its own. This makes the whole compilation much faster, and often leads to better optimised code, but it also requires much more memory. And it often results in compilation errors when headers included by different source files clash one with the other, or when using c static functions with the same name in different source files.
This is a good thing to do at packaging time, but of course not for developers, since a change in one file means recompiling everything. |
Source: http://developer.kde.org/documentation/other/developer-faq.html |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
lost+found Guru
![Guru Guru](/images/ranks/rank_rect_3.gif)
![](images/avatars/143288637951bc9a93074e6.gif)
Joined: 15 Nov 2004 Posts: 509 Location: North~Sea~Coa~s~~t~~~
|
Posted: Mon May 29, 2006 6:38 am Post subject: |
|
|
Thanks.
I think I will try it, booting up non graphical, 320 MB RAM + 2 x 512 MB SWAP in parallel on separate drives...
HA hA The monolithic ebuilds. Just for fun... ![Smile :-)](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
lost+found Guru
![Guru Guru](/images/ranks/rank_rect_3.gif)
![](images/avatars/143288637951bc9a93074e6.gif)
Joined: 15 Nov 2004 Posts: 509 Location: North~Sea~Coa~s~~t~~~
|
Posted: Wed May 31, 2006 10:04 am Post subject: |
|
|
lost+found wrote: | Thanks.
I think I will try it, booting up non graphical, 320 MB RAM + 2 x 512 MB SWAP in parallel on separate drives...
HA hA The monolithic ebuilds. Just for fun... ![Smile :-)](images/smiles/icon_smile.gif) |
Wow, this cuts off 30-40% compilation time. I saw no swapping at all, so I decided to continue compiling with xorg/kde running. Then I saw a small increase of swapspace usage. I guess some unused files from other processes...
Cheeeeeeeers.
Last edited by lost+found on Wed May 31, 2006 12:28 pm; edited 1 time in total |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Massimo B. Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
![](images/avatars/1411393680427a4354494d7.gif)
Joined: 09 Feb 2005 Posts: 1798 Location: PB, Germany
|
Posted: Wed May 31, 2006 10:31 am Post subject: |
|
|
I didn't notice swapping and the 640M physical ram were about 70 percent used. I just use this machine as usual under KDE while emerging with "kdeenablefinal" (PORTAGE_NICENESS="5"). _________________ HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Torangan Apprentice
![Apprentice Apprentice](/images/ranks/rank_rect_2.gif)
Joined: 21 Mar 2003 Posts: 178
|
Posted: Wed May 31, 2006 3:48 pm Post subject: |
|
|
Don't forget that this also opens up further optimization possibilities. A huge group of files is clumped together and since 3.4 GCC does have -funit-at-a-time (implied by -O2) which performs optimizations over the whole compilation unit. Using this option more code is put into one file so GCC does have more possibilities. Most intersting could be -O3 since more code in one unit means more potential for inlining. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|