This past week a new mailing list was created called kde-optimize (archive). The list is for developers who are willing to actively work on optimizing KDE or KDE applications, those who have profiled KDE or those who have the knowledge to help others optimize KDE. Two initial documents have already been created as part of this list. The first one is to teach users how they can improve the performance of their system. The second one is to give developers a starting point when looking to optimize applications.
Dot Categories:
Comments
Anyone tried compiling Qt and KDE with the Intel compiler?
Problem is not so much the compiler, it's the linker which would still be the same old slow one resolving relocations at startup...
The Intel compiler is furthermore not free and all. I suggest, we wait for DFA in gcc releases, then the Intel compiler should theoretically be overtaken, or not? The good thing about gcc will then be, Celeron, Athlon, i486 optimizations automatically near optimal, because a pipeline description will allow to simulate for best code/data flows...
That's advanced stuff... nobody say that gcc is not the best work ever. Just not for C++ ;-)
Yours, Kay
I don't think so. GCC doesn't even have a fully baked graph-based register allocator yet, let alone implementing some of the recent advances in compiler research that icc only recently has employed. GCC sadly still misses a lot of optimization opportunities that it can do but doesn't (just look in the bug database). The fact is they just don't have the sheer number of people and intellectual resources working on GCC as do many commercial groups.
And I don't see that changing any time soon with the GCC project having so many unnecessary artifical barriers to entry (read: FSF copyright assignment before code is accepted into the tree, having the codebase written in C, etc.)
On the bright side, GCC is probably one of the most "correct" compilers out there for (at least) C and C++.
> On the bright side, GCC is probably one of the most "correct" compilers out there for (at least) C and C++.
Oh yeah (gcc3):
#include
class A {
public:
virtual int foo ( unsigned long, ... ) = 0;
};
class B : virtual public A {
public:
int foo ( unsigned long a, ... ) { return 0; };
};
int main ( void ) {
B b;
return 0;
}
yup, that doesn't work. Still, g++ is better than msvc and borland IME.
(btw, that specific sort of bug with varargs is fixed in 3.3)
http://www.trolltech.com/developer/compilers/intel.html
QT3 works beautifully with icc. Much of KDE on the other hand won't build with ICC, mainly due to a few unsupported GNU extensions like statement-expressions.
As someone who has actually run C++ benchmarks between
GCC and Intel C, I can tell it would not help at
all with KDE. Intel is good in floating point number
crunching, but not at all better for integer and pointer
handling code, which is what a GUI mostly contains.
Hi!
Now (2006-03-19) QT 4.1.1 (latest from trolltech) was compiled "out-of-box" and working without problem via Intel's icc-9.0.030 (latest from Intel).
Gentoo 2006.0, Intel 920, EM64t
With best whishes - Yuriy Dmitriev.
Is 'just' a fairly abstract 'KDE-optimize' mailing list a thorough enough solution to an ever recuring issue of performance? For in the case of a KDE project, a developer cannot quickly drop in and review what the most relevant performance/optimization issues of a given project are. The source is very open, but most current project seem not very open about their code design.
Thus note that 'optimizing' might also count for inefficient organization of 'KDE-usability' or 'KDE-look', as I believe is also relevant. Not all KDE projects evolve around code, but all of them are based on an organization to which you could link efficiency/performance/progress rate.
'We' are already open-source, you might as well be open about your bottlenecks and code design for potential new developers. The 'performance bottleneck' of a mere KDE-optimize mailing list comes from the fact that you might not know a project by it's design in the first place. In the end you might find all your research was useless as your possible solution or approach was already considered/implemented.
Any serious attempt to optimize part of an application involves getting to read allot of the code and get a feel of the data flow, whereas it often might be usefull for the developers of a project (already aware of the current bottlenecks) to be public about this and mentioning design (diagrams) on their site or perhaps on a central 'KDE code design' site where developers can browse through to find relevant information about the project they are potentially interested in for helping.
So for developers it would be good to be able to browse per project what the bottlenecks are for each project and thus quickly browse a bit trough the relevant code. This way some more or less obvious 'slow' syntax can more quickly be resolved, or even be backed up by suggestions of improved datastructures for a given project.
Concluding this rant - each KDE project's code-leader can already improve optimize performance one step ahead by being more open about their project it's design approach. Detailed layouts of code designs lower the entrance bariere for potential new developers of interest so they can better review your project and decide wether to join, suggest radical new designs or offer mere syntax improvements.
IR said:
> blah blah blah
talk is cheap.
All you say is very theorical and could just apply to any projects. It looks like you never take the time to look at what KDE has been doing regarding speed improvements. I don't want to sound agressive, but do you think you are just the smart guy which will teach the KDE developers how to work ?
Please take the time to learn more about KDE before posting this kind of stuff. For you information:
1. Optimisation has always been in KDE developers mind. While there is no formal benchmark or process yet, developers regularly check the speed of the desktop and see where it could be generally improved. Browse kde-core-devel, you'll see benchmarks periodically.
So we do care about speed. I remember the KDE 2.0 release, which used a two month delay to get fantastic speed improvements at that time (tweaking with startup and kconfig).
The recent improvements of the Gnu toolchain regarding relocation and prelinking have been motivated by analysis perform by KDE developers or by people interested in improving KDE speed.
So please don't talk like we suddenly discovered that we could think about improving speed. It just wasn't as publicitely done as it may become now.
2. "Thus note that 'optimizing' might also count for inefficient organization"
This is why we are creating kde-optimise, to better cordinate any effort in improving KDE.
3. "In the end you might find all your research was useless as your possible solution or approach was already considered/ implemented."
We are not doing research but analysis and improvements. Big difference in approach. We don't analyse and present design for the fun of it, and just realise it does not apply. KDE, the projects and the developers have always been very pragmatic. If we analyse something, there will be a useful result, don't worry.
4. "Any serious attempt to optimize part of an application involves getting to read allot of the code and get a feel of the data flow"
And what do you think developer are doing everyday ? Check any development mailing-list and you will find people that are very aware of all KDE code (2.6 millions lines of code). Do you think main developers do not know their code or their data flow in their application ? What kind of developers would they be then ?
There also are plenty of generic tips to improve the speed of an application, are at least to avoid some bad constructs (using sytstem thinking sh is quick to start (while you are in fact starting bash) for example).
5. "This way some more or less obvious 'slow' syntax can more quickly be resolved, or even be backed up by suggestions of improved datastructures for a given project."
This is happening everyday.
So all in all, the only interesting thing in your post is to make design of applications more public. A good idea in itself, but you don't need so much blah blah to present it.
Also note that you learn a lot by reading source code. Although it requires an initial inestement before contributing, I am sure it helps to raise the level of contributors.
>>>All you say is very theorical and could just apply to any projects.
That was intended and not in a dictative form.
>>>It looks like you never take the time to look at what KDE has been doing regarding speed improvements.
First lets agree there are those projects we can regard as core projects and side projects. And I admit not knowing allot about the KDE (core) design, neither do I want to pretend to do. Neither am I able to other than to read allot of code only to learn about already known code designs (which can be argued a waste of time on my part, since diagrams or what not would have made that process allot more efficient).
>>> I don't want to sound agressive, but do you think you are just the smart guy which will teach the KDE developers how to work ?
No, do you think I am that stupid Philippe? I merely attempt to advise those developers who have so called 'side' projects to be more open about their application design such as to lower the barrier of entrance for overall most KDE side projects (or potential BETA branch projects). Obviously at some point you DO need to read allot of code, but it can be avoided to some extend. Its not a bad habit to be open about your code design and this does apply more to side projects then KDE's core as I fully respect is likely the case. Actually, I consider the KDE-core at an entire different design level since it is already a long ongoing project, unlike some newer projects.
>>>1. Optimisation has always been in KDE developers mind. While there is no formal benchmark or process yet, developers regularly check the speed of the desktop and see where it could be generally improved. Browse kde-core-devel, you'll see benchmarks periodically.
You seem to talk about 'the KDE developers mind'. Now I very well expect there to a 'common' KDE developers mind for core KDE parts.I believe however that for some coders it wouldn't be a bad habit to be more open about their design and lower the entrance bariere to potential new KDE killer-apps.
>>>So we do care about speed. I remember the KDE 2.0 release, which used a two month delay to get fantastic speed improvements at that time (tweaking with startup and kconfig).
I never argue *you* don't care for speed nor do I even dare to call my judgement over the performance of a project such as KDE-core.
>>>So please don't talk like we suddenly discovered that we could think about improving speed. It just wasn't as publicitely done as it may become now.
Please don't feel so attacked. You do agree that not all (side) projects are well designed and run be 'we'? Some people might want to be more open about their designs? I am not dictating anything, just wanting to give advise as I think it might be advise to some people?
>>>4. "Any serious attempt to optimize part of an application involves getting to read allot of the code and get a feel of the data flow"
>>>And what do you think developer are doing everyday ? Check any development mailing-list and you will find people that are very aware of all KDE code (2.6 millions lines of code). Do you think main developers do not know their code or their data flow in their application ? What kind of developers would they be then ?
That's my point. Not ALL projects get this kind of extensive reviewing and most have a 'high' barrier for review at all. Off-course developers should know their data flow. And wouldn't it be great if they mentioned this somewhere so would be new developers can more quickly join a (side) KDE project? At least, that's my opinion.
>>>So all in all, the only interesting thing in your post is to make design of applications more public. A good idea in itself, but you don't need so much blah blah to present it.
...'blah blah'
>>>Also note that you learn a lot by reading source code. Although it requires an initial inestement before contributing, I am sure it helps to raise the level of contributors.
...yes obviously. Still, potentially you might get more contributions for more projects if they are more open about general design approach. Plus its nice for any developer to 'quickly' learn a bit how KDE stuff ticks without extensive research. Obviously before any contribution more in-depth review is required!
KDE is a rather old project, so its very likely allot things have already been discussed so many newbies developers (like me) are likely to post old ideas/suggestions 'again' and again sounding dictating in the process, all the while just trying to help.
Sorry, I was a bit verbose about speed issues because many seem to believe that KDE developers are not aware of optimisation issues, or never thought about optimising KDE.
So basically you suggest to have more open designs for less mainstream applications. I say it is a good idea. Ideally, every kde app would have a sourceforge like project page to discuss its development and expalin its design.
You can find this kind of design answer by simply asking on a mailing-list. Not as friendly as reading a design document, but still very efficient.
I am relatively new regarding programming for Linux and using Linux in general. When Mandrake 9.0 came out, I switched 100% from windows to Linux (now using Gentoo). Open source is such an enormous powerfull entity in itself. Again and again I am also am amazed by KDE abilities and potential abilities. Not to mention how volunteers organize themselves in such a professional/effective way. I guess you can say that Windows blinds users but also allot of developers sadly.
What I personally found over time is that it can be argued there is a KDE user barrier, there is also a developers barrier. Its just that I can see much potential in open standards/code the more I am involved in utilizing/developing these, the more I sometimesfeel sorry not to see developers being open about their designs. Because its finaly these designs which are also out in the open.
Some time ago I read an extensive article about the Reiser file system and through it the developers gave me a look into how it works also related to its datastructures. This allowed me to learn allot more about its design without having to read trough allot of abstract code. I think this is great because more developers can anticipate and more quickly react on it this way.
Its also just nice for any technically minded KDE person to see better how KDE ticks. Perhaps its like an automobile. Its engine is openly available, but nice layouts of its design and how it works is pleasing also to non mechanics.
You have a good deal of information on
http://developer.kde.org/documentation/library/kdeqt/kde3arch/index.html
But I understand what you mean. This is open source, you must help yourself.
Let's see..
KDE becomes more slow each release. Ok, I have an old PII with 64MB, but
that isn't the issue.
I installed a Linux with KDE 2.1 for a friend in its still older Pentium 233, and it's yet faster than my KDE 3.
I discussed this with Aaron Seigo and its KDE3 on 64MB computer mith, and we didn't agree.
Konqueror is a special concern. It LEAKS MEMORY. After an hour or so, it eats all the computer resources at the point you must kill it or throw yourself thru a window.
I hope KDE becomes better, but I do not believe it becomes faster in newer versions.
Upgrade the system.. seriously. I think it's too much of a drain for programmers to on one hand add new features and support ancient hardware. It held back Apple for a long time (supporting 68k hardware).. it has always dogged Microsoft (until XP). Of course, those two, who are certainly the major players in the desktop market now-days don't care much for old hardware such as Pentium 233's... try running OSX or XP on something like that (or for that matter, try running win2k and MacOS 9.2 on it.. it'll be slow, but workable.. sorta like KDE is). If KDE (and Linux) wants to grab more market share, it must continue adding features. This is what the mass-consumer wants. This is how, for example, Microsoft Office became predominant (after years of WordPerfect/Lotus 123).. Microsoft just added all of the comptetitors' features in their products.
I suggest you use something like fluxbox on it.
Well, some things have definitely become slower with KDE 3, konsole, some things in kmail, but e.g. kmail in 3.1. is much faster than in 3.0.
Nevertheless, 3.1 runs usable on my old K6/200 128 MB.
Bye
Alex
Don't forget konqueror!
In KDE3.1 it's really faster!
It isn't that KDE is slower with each release, it is that it gets bigger with each release. It now takes 128 MB (192 MB is better) to run it. If you have less memory, Linux becomes slow because of the constant VM swaps.
"New KDE release out" doesn't mean you have to
run it in your, say, 266/64MB system.
For example KDE just flies on Athlon 1.6/256MB.
And I've been using KDE 3.01 on Celeron/500/196MB
just fine.
What exactly most people expect when talking
about speed?
Sure, Gnome loads faster, but this is mostly
because it has 1/4 of the functionality.
If you use a slower computer there are some things which take quite a long time - enough so that you feel held up waiting for it to respond. For example - opening new tabs on Konqueror in 3.1 is slow on my laptop (takes a second or so) or opening the Konqueror configuration window which causes the computer to sit there hammering away at the disk for several seconds.
Also, switching between desktops feels noticably slower in KDE compared to other window managers even when running exactly the same applications - for this reason I run Windowmaker on my laptop even though I don't like it :)
I would really like to see KDE use less memory - it seems to fill most of my 128MB laptop, which means that slows down if I start using the memory for anything else. However, the KDE developers are getting a handle on the memory leaks in the 3.1 release candidates.
I did some profiling of the delay in opening new tabs, but I didn't get very far as the debian QT package does not contain symbols so the only results I got was that 90% of the time was spent somewhere in QT. I'm going to do some more serious work once the Debian transition to gcc 3.2.x has progressed a little more.
Of course, there's the standard complaint about slow application start up times. Prelink improves matters a bit (and overall KDE start up an incredible amount), but there are still stability problems with it (at least Kword is less stable, but it might not be the latest version)
In summary, I feel KDE is just generally a bit sluggish and unresponsive in certain places.
who don't really care about java or c++ ... gcc is a compiler for systems level programming ... i.e. Unix kernels (and a shrinking bit of NT W2K XP internals) ... C is like fortran it won't go away and since the difference between writing a kernel and compiler is less than it is between writing a GUI and compiler, theres no way GCC maintainers will ever make gcc/g++ and linkers optimal for C++.
I pin my hopes on Trolltech releasing a free/commercial compiler so linux/bsd GUI's can be properly compiled and linked ....
You should take a look at the following article:
http://osnews.com/comment.php?news_id=2534
Seems like Apple isn't only contributing code to KHTML.. :)