Hello fellow openSUSE hackers. So far we have a few people to start this project to optimize certain parts of openSUSE, but as usual the more the better. Maybe we just present each other and start from there with expectations and capabilities. I start and once we have identified anyone that is interested we can move this discussion offlist. We need anyone with any skill and capabilities to inject some steroids into an already fantastic distribution. My name is Andreas Girardet and I work for Novell as Consultant in NZ. I am the founder of and used to be maintainer of Yoper "Your Operating System" an optimised from scratch Desktop distro (I have stepped out of Yoper at the beginning of the year). My main goal is and always has been to make the Linux migrants' experience a very positive one. I am very excited about openSUSE as I believe it is the first commercial grade distro (as far as I am aware) that has a completely Open development model. As opposed to an open distro trying to be commercial (with drawbacks) or the other big commercial distro not really supporting its open "step" child and just using it as a test bed for technologies as opposed to its main source tree. My experience are mainly in packaging, System Administration and I am overall a resource of boundless enthusiasm, which can be highly infectious. My expectation is to 1.) Create a openSUSE / SUSE based desktop, that is at least as fast and snappy as windows. Most peoples' experience of Linux on the desktop is at first a disappointment, when it comes to speed since some distro's do run significantly slower than Windows. NLD and SUSE is not an exception and ex windows users in the Novell office complain about this and welcome my little tweaks here and there to make it snappier. But I rather have a solution to the issue instead of hacking and tweaking single systems again and again. 2.) Create a test case with a written proof of concept of such a desktop to lay in front of the openSUSE community. Plan is to release a first desktop at the same time with 10.0 going gold. This testcase should have a written design with respective outcomes/deliverables and a spread sheet with tests we can do against openSUSE standard and openSUSE on steroids. I would call it SUPER ...:D SUSE Performance Enhanced Release ... only kidding, but we do need some sort of codename for this. We can use this testcase also as a business case to put in front of Novell/SUSE internally here to put some ressources into moving things aggressively into a more optimised desktop direction as I believe this will be the one key differentiator moving forward in the battle of the desktops. 3.) Personally I want to stay as close as possible to the openSUSE code, since this means that each openSUSE release gets followed on the day by our "addon" packages. Those packages should and could be installed on top of an existing openSUSE install or for convenience sake we could also create a 1 CD base desktop distro a user can download and install quickly and then install additional packages onto with Yast or Kynaptic/Synaptic against the gwdg.de repository , which I personally really like. We could also create a mini install containing <150 base packages on top of which a geek can install the rest. A real minimal install, which I personally also like. In short I do not want to create a new distro out of this or a fork that requires large amounts of code maintenance, since IMHO that would be futile and certainly something that is in my eyes not really required and quite pointless, I certainly would not want to be part of such a fork. The maintenance will be done by the wider community anyway, we just take it and mold something out of it that we think is faster, better, stronger ;) ....... SUSE on steroids. I am sure SUSE research can use some things we will do in future releases and we certainly will do whatever SUSE research thinks could improve performance. 4.) Personally I have some time I can dedicate to this, possibly 20-30 hours per week. My focus can be on the design and the packaging. I think we can easily have something ready by the time SUSE 10 goes gold. 5.) Personally, we should have scripts at the end of this which automatically create our custom version out of each SUSE release. That we we can spend time fine tuning instead of constant hacking and packaging. I can also already give us all an account on a buildserver on a 100Mbit in the US I set up. Please let me know if you want access to it. So if you are still keen, reply and present yourself and tell us about your expectations. We should at some point move this offlist or onto another list, since I am sure others on this list don't want to constantly read our ramblings ;) Thanks for those who listened and GO SUSE GO! Thanks so much for openSUSE .... a dream come though .... Regards, Andreas Girardet Consulting Architect Novell, Inc., the leading provider of information solutions http://www.novell.com My phonenumbers: NZ Mobile: 0064-027-645-9827 NZ Landline: 0064-09-3081400
Andreas Girardet wrote:
Hello fellow openSUSE hackers.
So far we have a few people to start this project to optimize certain parts of openSUSE, but as usual the more the better. Maybe we just present each other and start from there with expectations and capabilities. I start and once we have identified anyone that is interested we can move this discussion offlist. We need anyone with any skill and capabilities to inject some steroids into an already fantastic distribution.
My name is Andreas Girardet and I work for Novell as Consultant in NZ. I am the founder of and used to be maintainer of Yoper "Your Operating System" an optimised from scratch Desktop distro (I have stepped out of Yoper at the beginning of the year). My main goal is and always has been to make the Linux migrants' experience a very positive one.
I am very excited about openSUSE as I believe it is the first commercial grade distro (as far as I am aware) that has a completely Open development model. As opposed to an open distro trying to be commercial (with drawbacks) or the other big commercial distro not really supporting its open "step" child and just using it as a test bed for technologies as opposed to its main source tree. My experience are mainly in packaging, System Administration and I am overall a resource of boundless enthusiasm, which can be highly infectious.
My expectation is to
1.) Create a openSUSE / SUSE based desktop, that is at least as fast and snappy as windows. Most peoples' experience of Linux on the desktop is at first a disappointment, when it comes to speed since some distro's do run significantly slower than Windows. NLD and SUSE is not an exception and ex windows users in the Novell office complain about this and welcome my little tweaks here and there to make it snappier. But I rather have a solution to the issue instead of hacking and tweaking single systems again and again.
2.) Create a test case with a written proof of concept of such a desktop to lay in front of the openSUSE community. Plan is to release a first desktop at the same time with 10.0 going gold. This testcase should have a written design with respective outcomes/deliverables and a spread sheet with tests we can do against openSUSE standard and openSUSE on steroids. I would call it SUPER ...:D SUSE Performance Enhanced Release ... only kidding, but we do need some sort of codename for this. We can use this testcase also as a business case to put in front of Novell/SUSE internally here to put some ressources into moving things aggressively into a more optimised desktop direction as I believe this will be the one key differentiator moving forward in the battle of the desktops.
3.) Personally I want to stay as close as possible to the openSUSE code, since this means that each openSUSE release gets followed on the day by our "addon" packages. Those packages should and could be installed on top of an existing openSUSE install or for convenience sake we could also create a 1 CD base desktop distro a user can download and install quickly and then install additional packages onto with Yast or Kynaptic/Synaptic against the gwdg.de repository , which I personally really like. We could also create a mini install containing <150 base packages on top of which a geek can install the rest. A real minimal install, which I personally also like.
In short I do not want to create a new distro out of this or a fork that requires large amounts of code maintenance, since IMHO that would be futile and certainly something that is in my eyes not really required and quite pointless, I certainly would not want to be part of such a fork. The maintenance will be done by the wider community anyway, we just take it and mold something out of it that we think is faster, better, stronger ;) ....... SUSE on steroids. I am sure SUSE research can use some things we will do in future releases and we certainly will do whatever SUSE research thinks could improve performance.
4.) Personally I have some time I can dedicate to this, possibly 20-30 hours per week. My focus can be on the design and the packaging. I think we can easily have something ready by the time SUSE 10 goes gold.
5.) Personally, we should have scripts at the end of this which automatically create our custom version out of each SUSE release. That we we can spend time fine tuning instead of constant hacking and packaging.
I can also already give us all an account on a buildserver on a 100Mbit in the US I set up. Please let me know if you want access to it.
So if you are still keen, reply and present yourself and tell us about your expectations. We should at some point move this offlist or onto another list, since I am sure others on this list don't want to constantly read our ramblings ;)
Thanks for those who listened and GO SUSE GO! Thanks so much for openSUSE .... a dream come though ....
As I have already chatted with Andreas off list about this, I will just briefly state that I am working with him on this. Like Andreas, I live in NZ. I spent about 3 years working for Lycoris on Desktop/LX (now a Mandriva product I guess). I work doing kernel support for Linux and *BSD and have just started a new role as an embedded Linux engineer. Anyways, my intentions are inline with what Andreas as stated, so no need to rehash them ;) Mike
Hi, I'm currently testing SUSE Linux 10.0 Beta 1 on two machines here. (One Notebook, One Desktop) I really like the way Novell is going with SUSE Linux. But one thing, I always disliked at SUSE Linux is the lack of speed. I also thought about tweaking config-files and so on, to have a faster system. Because of that, I'm highly interested in what your project will come out with, and I also want to offer my help. My programming skills are really bad. (Only read the first chapter in a book about C, little BASIC/PASCAL Skills (I think they won't help ;-)), and medium JavaScript-Skills.) So I can't help you with programming itself, but I know some basic things that are necessary to communicate with programmers. I could help testing, tweak configurations, write documentation and help the community. Personal Info: 19yrs. from Germany. E-Mail: matthias.eckert@gmail.com If you need my help, please write me an e-mail or comment on this. Thanks, Matthias Eckert
On Mon, Aug 15, 2005 at 02:56:24PM +0200, Matthias Eckert wrote:
Hi,
I'm currently testing SUSE Linux 10.0 Beta 1 on two machines here. (One Notebook, One Desktop) I really like the way Novell is going with SUSE Linux. But one thing, I always disliked at SUSE Linux is the lack of speed. I also thought about tweaking config-files and so on, to have a faster system. Because of that, I'm highly interested in what your project will come out with, and I also want to offer my help. My programming skills are really bad. (Only read the first chapter in a book about C, little BASIC/PASCAL Skills (I think they won't help ;-)), and medium JavaScript-Skills.) So I can't help you with programming itself, but I know some basic things that are necessary to communicate with programmers. I could help testing, tweak configurations, write documentation and help the community.
Specify "lack of speed". Where? We worked hard on enhancing boot time speeds for instace. ;) Ciao, Marcus
El Lunes, 15 de Agosto de 2005 14:58, Marcus Meissner escribió:
On Mon, Aug 15, 2005 at 02:56:24PM +0200, Matthias Eckert wrote:
Hi,
I'm currently testing SUSE Linux 10.0 Beta 1 on two machines here. (One Notebook, One Desktop) I really like the way Novell is going with SUSE Linux. But one thing, I always disliked at SUSE Linux is the lack of speed. I also thought about tweaking config-files and so on, to have a faster system. Because of that, I'm highly interested in what your project will come out with, and I also want to offer my help. My programming skills are really bad. (Only read the first chapter in a book about C, little BASIC/PASCAL Skills (I think they won't help ;-)), and medium JavaScript-Skills.) So I can't help you with programming itself, but I know some basic things that are necessary to communicate with programmers. I could help testing, tweak configurations, write documentation and help the community.
Specify "lack of speed". Where?
We worked hard on enhancing boot time speeds for instace. ;)
I understand Matthias very well. I run Suse 9.3 on a Pentium IV 2.0 GHz with 768MB RAM and I also installed it in my sister's Pentium III 866MHz with 256MB. Well, I find my sister's computer to run Suse faster than mine. Yes, I'm not kidding. It can be appreciated, for example, in program start times. I haven't used a chronometer to know exactly the difference, but for example in her computer I click at the Konqueror icon and it just opens; in my computer it takes 4 or 5 seconds to open. And the hard disk makes a strage sound I haven't heard before while it's being accessed BTW, while in other distros and in older versions of Suse it worked perfectly. So I have no idea why it happens, but there's something strange with it. -- Víctor Fernández Martínez Gabinete de prensa de PoLinux [www.polinux.upv.es]. Usuario de Linux registrado #312284 en http://counter.li.org.
On Mon, 15 Aug 2005, Víctor Fernández Martínez wrote:
I understand Matthias very well. I run Suse 9.3 on a Pentium IV 2.0 GHz with 768MB RAM and I also installed it in my sister's Pentium III 866MHz with 256MB. Well, I find my sister's computer to run Suse faster than mine. Yes, I'm not kidding. It can be appreciated, for example, in program start times. I haven't used a chronometer to know exactly the difference, but for example in her computer I click at the Konqueror icon and it just opens; in my computer it takes 4 or 5 seconds to open. And the hard disk makes a strage sound I haven't heard before while it's being accessed BTW, while in other distros and in older versions of Suse it worked perfectly. So I have no idea why it happens, but there's something strange with it.
I guess you should try to install and run the smartmontools. Probably something bad happens with your harddisk ... Berthold -- ------------------------------------------------------------------ Berthold Gunreben SUSE Linux GmbH -- Dokumentation mailto:bg@suse.de Maxfeldstr. 5 http://www.suse.de/ D-90409 Nuernberg, Germany
El Lunes, 15 de Agosto de 2005 15:49, Berthold Gunreben escribió:
I guess you should try to install and run the smartmontools. Probably something bad happens with your harddisk ...
Ok, I'll try, but why should I think it isn't a Suse 9.3 issue while it works perfectly on Debian and on Suse 9.2? -- Víctor Fernández Martínez Gabinete de prensa de PoLinux [www.polinux.upv.es]. Usuario de Linux registrado #312284 en http://counter.li.org.
On Mon, 15 Aug 2005, Víctor Fernández Martínez wrote:
El Lunes, 15 de Agosto de 2005 15:49, Berthold Gunreben escribió:
I guess you should try to install and run the smartmontools. Probably something bad happens with your harddisk ...
Ok, I'll try, but why should I think it isn't a Suse 9.3 issue while it works perfectly on Debian and on Suse 9.2?
To be honest: I don't know. It is just a wild guess, because harddisks should not sound bad ... A new installation of a distribution could also trigger latent harddisk errors‥ Berthold -- ------------------------------------------------------------------ Berthold Gunreben SUSE Linux GmbH -- Dokumentation mailto:bg@suse.de Maxfeldstr. 5 http://www.suse.de/ D-90409 Nuernberg, Germany
Marcus Meissner wrote:
Specify "lack of speed". Where?
Yeah, where? I'm running SuSE 9.3 Pro on an Intel Pentium 4 HT 3 GHz 1 MB L2 800 MHz FSB processor on an Intel 915GAV motherboard with 512 MB of 400 MHz DDR-RAM installed dual-channel (giving 800 MHz effective output to keep pace with the mu-p's FSB), and I've not had any particular complaints for speed. Except:
We worked hard on enhancing boot time speeds for instace. ;)
Well, I felt Windows XP loaded faster than SuSE 9.3. Maybe boot time is a lot lesser than previous version, but at least on my system Windows XP (Pro, with SP1) boots faster. -- Shriramana Sharma http://samvit.org
Shriramana Sharma schrieb:
Marcus Meissner wrote:
Specify "lack of speed". Where?
Yeah, where? I'm running SuSE 9.3 Pro on an Intel Pentium 4 HT 3 GHz 1 MB L2 800 MHz FSB processor on an Intel 915GAV motherboard with 512 MB of 400 MHz DDR-RAM installed dual-channel (giving 800 MHz effective output to keep pace with the mu-p's FSB), and I've not had any particular complaints for speed. Except:
We worked hard on enhancing boot time speeds for instace. ;)
Well, I felt Windows XP loaded faster than SuSE 9.3. Maybe boot time is a lot lesser than previous version, but at least on my system Windows XP (Pro, with SP1) boots faster.
Don't forget that XP is a little cheating here. They start to load a lot of system things after a user logs in. Well, same applies when KDE starts ... but at least I can start to work once the KDE splash disappears. On XP you are constantly forced to wait until all the little tools and services and whatever is started. -- Stephan A. Rickauer ---------------------------- Institut für Neuroinformatik Universität / ETH Zürich Winterthurerstriasse 190 CH-8057 Zürich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch ----------------------------
On Mon, Aug 15, 2005 at 3:29 pm, in message <430098A6.9090505@ini.phys.ethz.ch>, stephan.rickauer@ini.phys.ethz.ch wrote: Shriramana Sharma schrieb: Marcus Meissner wrote:
Specify "lack of speed". Where?
Yeah, where? I'm running SuSE 9.3 Pro on an Intel Pentium 4 HT 3 GHz 1 MB L2 800 MHz FSB processor on an Intel 915GAV motherboard with 512 MB of 400 MHz DDR- RAM installed dual- channel (giving 800 MHz effective output to keep pace with the mu- p's FSB), and I've not had any particular complaints for speed. Except:
We worked hard on enhancing boot time speeds for instace. ;)
Well, I felt Windows XP loaded faster than SuSE 9.3. Maybe boot time is a lot lesser than previous version, but at least on my system Windows XP (Pro, with SP1) boots faster.
Don't forget that XP is a little cheating here. They start to load a lot of system things after a user logs in. Well, same applies when KDE starts ... but at least I can start to work once the KDE splash disappears. On XP you are constantly forced to wait until all the little tools and services and whatever is started.
I just installed SUSE 10 Beta 1 on one machine, and the time from power switch to login screen was 16 *seconds* The time from login to desktop was about the same as in 9.3 I also note that SUSE 10 seems to have a working warm reboot (no BIOS POST on reboot), which at least for me is a first in linux, and that really speeds up reboots
On Tue, Aug 16, 2005 at 1:13 am, in message <4300950A.8020508@gmail.com>, samjnaa@gmail.com wrote: Marcus Meissner wrote:
Specify "lack of speed". Where?
Yeah, where? I'm running SuSE 9.3 Pro on an Intel Pentium 4 HT 3 GHz 1 MB L2 800 MHz FSB processor on an Intel 915GAV motherboard with 512 MB of 400 MHz DDR- RAM installed dual- channel (giving 800 MHz effective
output to keep pace with the mu- p's FSB), and I've not had any particular complaints for speed. Except:
We worked hard on enhancing boot time speeds for instace. ;)
Well, I felt Windows XP loaded faster than SuSE 9.3. Maybe boot time is a lot lesser than previous version, but at least on my system Windows XP (Pro, with SP1) boots faster.
You have a state of the art system, which would run fast regardless of OS. Try a basic laptop or office machine and you will see that speed very much becomes an issue. Andreas
A system that feels fast to the user is important and I really appreciate this. I just like to make one request: Please develop some kind of benchmarks and reproduceable tests so that we all can measure the difference. Real numbers speak for themselves... Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
A system that feels fast to the user is important and I really appreciate this. I just like to make one request:
Please develop some kind of benchmarks and reproduceable tests so that we all can measure the difference. Real numbers speak for themselves...
That could be a tricky thing. The question is: How does one measure that a system "feels fast/responsive"? I think that this is mostly based on personal impressions of a user and it's not that easy to express this by numbers. However there has been some work for measuring responsiveness of the Kernel by Con Kolivas. His tool is called interbench (interbench.kolivas.org). Maybe this is a good point to start. -- Jens Siebert
Jens Siebert
Andreas Jaeger wrote:
A system that feels fast to the user is important and I really appreciate this. I just like to make one request: Please develop some kind of benchmarks and reproduceable tests so that we all can measure the difference. Real numbers speak for themselves...
That could be a tricky thing. The question is: How does one measure that a system "feels fast/responsive"? I think that this is mostly based on personal impressions of a user and it's not that easy to express this by numbers.
Some things that come directly to my mind: * bootspeed * How long does it take on a freshly started system to start OOo? * under a defined workload (some disk I/O work), how long does a certain (to be defined) action take. Those are hardware dependend but on the same hardware with a fresh installation (a defined test system), the performance enhancements should show a difference.
However there has been some work for measuring responsiveness of the Kernel by Con Kolivas. His tool is called interbench (interbench.kolivas.org). Maybe this is a good point to start.
It might be a start if it is close enough to real workloads, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
However there has been some work for measuring responsiveness of the Kernel by Con Kolivas. His tool is called interbench (interbench.kolivas.org). Maybe this is a good point to start.
It might be a start if it is close enough to real workloads,
As far as I know this is one of the goals of interbench. -- Jens Siebert
>>> aj@suse.de 08/18/05 12:58 pm >>> > * How long does it take on a freshly started system to start OOo? I would like to see some work be done on "cheating" the same way windows does it. IOW to show the window as quickly as possible, and populate it piece by piece. While this isn't faster in the strictest sense of the word, it does give the impression of being faster, and many end users measure feeling, as was mentioned. I know this has been done in a few places, but I think it still needs more work I suspect this falls outside the scope of this project though. BTW, I found a few comments about profiling tools for X on some other mailing list, Perhaps we could try to integrate all the various tools into one suite, for easy access
>>> ajohansson@novell.com schrieb am Do, Aug 18, 2005 um 11:45 pm in Nachricht <430490FF.A02D.0008.0@novell.com>: >>>> aj@suse.de 08/18/05 12:58 pm >>> >> * How long does it take on a freshly started system to start OOo? > > I would like to see some work be done on "cheating" the same way > windows does it. IOW to show the window as quickly as possible, and > populate it piece by piece. While this isn't faster in the strictest > sense of the word, it does give the impression of being faster, and many > end users measure feeling, as was mentioned. I know this has been done > in a few places, but I think it still needs more work > > I suspect this falls outside the scope of this project though. > Are you referring to caching files for bootup? Preload could do that I think or readahead from Fedora. Certainly something I want to put enabled at install. IMHO it is inside the scope. Whatever we can do in an out of the box scenario to make things faster or add an experimental feature that we would like we can add in SUPER. Performance enhanced does not only mean speed and I personally rather consider SUPER to be the place we can try things out and be more aggressive than in the stable and general purpose standard SUSE Linux release. Meaning any feature we cannot do in the mainstream release, but want to have tested and maintained we can put into this supercharged repository. Such caching is stricly a speed increase anyhow and as such certainly part of the whole. > BTW, I found a few comments about profiling tools for X on some other > mailing list, Perhaps we could try to integrate all the various tools > into one suite, for easy access > Good idea, fire things through or even better just add them yourself to the SUPER wiki site on opensuse.org. AG
On 8/18/05, Anders Johansson
* How long does it take on a freshly started system to start OOo?
I would like to see some work be done on "cheating" the same way windows does it. IOW to show the window as quickly as possible, and populate it piece by piece.
Hey guys, these are UI design basics. This is definitely the way it should always be done, if possible. So not just with OO.org. It's just that with current (application) architectures this may not be too easy to do :/. It would probably require a Qt fork among other things..
While this isn't faster in the strictest sense of the word,
Yep, but usually you don't need the 1000x ultra-cool-gizmos at the startup - if you can start typing or viewing the document, users are happy. But the dependencies within the code may make doing this impossible. And this is probably what we would be facing here. That said, i'd guess that this is where most of the windows's responsiveness comes from. So most of the delays we have are on application side - and there's just not that much we can do about it other than fixing applications. -- // Janne
On Thu, Aug 18, 2005 at 12:58:50PM +0200, Andreas Jaeger wrote:
Some things that come directly to my mind: * bootspeed
For this tBootchard could be included in the distro: http://www.bootchart.org/index.html My unalterd 9.3 looks like this: http://houghi.org/shots/bootchart.png houghi -- Even if you do learn to speak correct English, whom are you going to speak it to? -- Clarence Darrow
Andreas Jaeger wrote:
Some things that come directly to my mind: * bootspeed * How long does it take on a freshly started system to start OOo? * under a defined workload (some disk I/O work), how long does a certain (to be defined) action take.
For optimization of application startup times I think this should be considered: (from the gcc 4.0 changelog) The -fvisibility option has been added which allows the default ELF visibility of all symbols to be set per compilation and the new #pragma GCC visibility preprocessor command allows the setting of default ELF visibility for a region of code. Using -fvisibility=hidden especially in combination with the new -fvisibility-inlines-hidden can yield substantial improvements in output binary quality including avoiding PLT indirection overheads, reduction of the exported symbol count by up to 60% (with resultant improvements to link and load times), better scope for the optimizer to improve code and up to a 20% reduction in binary size. Using these options correctly yields a binary with a similar symbol count to a Windows DLL. Perhaps more importantly, this new feature finally allows (with careful planning) complete avoidance of symbol clashes when manually loading shared objects with RTLD_GLOBAL, thus finally solving problems many projects such as python were forced to use RTLD_LOCAL for (with its resulting issues for C++ correctness). You can find more information about using these options at http://gcc.gnu.org/wiki/Visibility. -- Jens Siebert
On Thursday 18 August 2005 17:17, Jens Siebert wrote:
Andreas Jaeger wrote:
Some things that come directly to my mind: * bootspeed * How long does it take on a freshly started system to start OOo? * under a defined workload (some disk I/O work), how long does a certain (to be defined) action take.
For optimization of application startup times I think this should be considered:
(from the gcc 4.0 changelog)
The -fvisibility option has been added which allows the default ELF
already used in KDE on SL 10.0 -- Adrian Schroeter SuSE AG, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
Adrian Schroeter wrote:
For optimization of application startup times I think this should be considered:
(from the gcc 4.0 changelog)
The -fvisibility option has been added which allows the default ELF
already used in KDE on SL 10.0
Good! But KDE makes no Linux Distro ;-) Are there any noticeable differences in startup times for KDE? (I have not tested any of the betas yet because I have no access to a broadband connection until next week) -- Jens Siebert
On Thursday 18 August 2005 22:52, Jens Siebert wrote:
Adrian Schroeter wrote:
For optimization of application startup times I think this should be considered:
(from the gcc 4.0 changelog)
The -fvisibility option has been added which allows the default ELF
already used in KDE on SL 10.0
Good! But KDE makes no Linux Distro ;-) Are there any noticeable differences in startup times for KDE? (I have not tested any of the betas yet because I have no access to a broadband connection until next week)
yes, but I forgot the values. You should be able to find it in http://lists.kde.org . Either kde-core-devel or kde-optimize list. -fvisibility can only be used, if the projects did prepared the usage for it. So that is the reason why only KDE has it atm afaik. bye adrian -- Adrian Schroeter SuSE AG, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
Adrian Schroeter wrote:
Good! But KDE makes no Linux Distro ;-) Are there any noticeable differences in startup times for KDE? (I have not tested any of the betas yet because I have no access to a broadband connection until next week)
yes, but I forgot the values. You should be able to find it in http://lists.kde.org . Either kde-core-devel or kde-optimize list.
-fvisibility can only be used, if the projects did prepared the usage for it. So that is the reason why only KDE has it atm afaik.
Ah ok... I didn't know that. I will test it for myself next week... -- Jens Siebert
On Thu, Aug 18, 2005 at 10:08:46AM +0200, Jens Siebert wrote:
Andreas Jaeger wrote:
A system that feels fast to the user is important and I really appreciate this. I just like to make one request:
Please develop some kind of benchmarks and reproduceable tests so that we all can measure the difference. Real numbers speak for themselves...
That could be a tricky thing. The question is: How does one measure that a system "feels fast/responsive"?
You get a big big big IBM Server with like 12 CPUs and a couple Gigs of RAM, and hack MS-DOS to find that much RAM and Processors, and THEN it's fast :)
personal impressions of a user and it's not that easy to express this by numbers. However there has been some work for measuring responsiveness of the Kernel by Con Kolivas. His tool is called interbench (interbench.kolivas.org). Maybe this is a good point to start.
--
Jens Siebert
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org
El Jueves, 18 de Agosto de 2005 14:36, Allen escribió:
You get a big big big IBM Server with like 12 CPUs and a couple Gigs of RAM, and hack MS-DOS to find that much RAM and Processors, and THEN it's fast :)
And you get an old 286 with 1 MB RAM and install Windows XP. THEN you'll remember the times of the ENIAC when you had to drill a card, put it in the drive and wait 20 minutes for the valves to warm up. ;) -- Víctor Fernández Martínez Gabinete de prensa de PoLinux [www.polinux.upv.es]. Usuario de Linux registrado #312284 en http://counter.li.org.
Please develop some kind of benchmarks and reproduceable tests so that we all can measure the difference. Real numbers speak for themselves...
Thanks a lot Andreas I think this is a good idea. Good tips regarding benchmarking in your other email too. Will be collating the info on the benchmarking page on the WIKI and include it on the SUPER site. Any more ideas from anyone? The more we can put together the better. AG
participants (15)
-
Adrian Schroeter -
Allen -
Anders Johansson -
Andreas Girardet -
Andreas Jaeger -
Berthold Gunreben -
houghi -
Janne Karhunen -
Jens Siebert -
Marcus Meissner -
Matthias Eckert -
Michael Honeyfield -
Shriramana Sharma -
Stephan A. Rickauer -
Víctor Fernández Martínez