Kernel Cousin KDE #30 Is Out

Friday, 18 January 2002  |  Rkaper

Aaron J. Seigo delivers again with Kernel Cousin KDE #30. This week the summaries of the development mailing-lists include talk about KDE 3.1 features, Debian package maintainance, KDE artwork, GCC3 and the new KDE::Enterprise Forum. Enjoy!

Comments:

Faster startup with GCC3? - Juan Ignacio - 2002-01-18

Hi all, Is it true that GCC3 has a kind of objprelink capability, so the startup time of the applications are going to be more faster than the actual ones? Thank you for any info. Juan Ignacio.

Re: Faster startup with GCC3? - anonymous - 2002-01-19

It's false. But recent versions of ld have a -z combreloc option (which is enabled by default) which helps to improve startup performance.

Focus on speed now - Anonymous Coward - 2002-01-18

Hi, Wouldn't it really be nice if <b>all</b> the KDE hackers, before rushing out KDE3, would spend and additional two weeks (or even a month) just addressing performance issues. We know that khtml got some tuneups recently, but khtml is one thing (although it is a very important one!), but there are many others. The biggest thing might still be the poor startup performance. Following the kde-cvs and kde-devel Mailing lists, recently there were some threads where some hackers meant that they could enhance KDE's speed by at least 30%-50% by not using certain C++ features that have huge overhead. (Virtual functions IIRC) See this poll where "Speed" is the biggest wish of currently 50% of all votes: http://kde-look.org/poll/poll.php?poll=5&PHPSESSID=43300db09b4ea01983705312b0a47fa1 I love KDE, it is what made me quit using windows Anonymous Coward

Re: Focus on speed now - Bryan Feeney - 2002-01-18

've no experience of KDE code, but I know C++, and virtual functions are a pretty core part of what makes C++ such a powerful language. It is possible you could conceive an alternative using templates, but that would bloat the size of libraries and apps trememdously. Then you'd have performance problems 'cause it would take up too much memory! It's basically not something you can simply scrap for speed. In response to the first comment on GCC3 speed ups, it's got better support for C++ generally, and does a better job with the linker, but from what I've heard we won't see any real improvement till GCC 3.1.

Re: Focus on speed now - Anonymous Coward - 2002-01-18

Here are the details (read the whole thread) : http://lists.kde.org/?l=kde-cvs&m=101083409300315&w=2 (I've only recently started C++, sorry for being not precise)

Re: Focus on speed now - dB - 2002-01-18

Ok, hi. I'm a windows user. Yeah, bring on the flames. I also use KDE (unsurprising, really, I didn't end up here by random IE clicks). Let me address the point above. I'm a C++ coder, nothing under linux it's all 'doze based, but the principles are the same. Virtual functions are gonna give you code overhead. They do reduce the speed of your code, because you're trying to maintain a vtable of functions (strictly "class methods") that have been derived from a different source. It is incredibly easy not to use virtual functions. Want to know how easy? Its the difference between this: virtual void woot(int a); and void woot(int a); Not much difference eh. I have no freakin idea why this guy is recommending you use template classes instead of virtual functions - hello? they are 2 different things. Go hit yourself with a copy of C++ for Dummies. For those of you who find that book too confusing, it's as simple as this - put a virtual function in a base class, and you are forced to include it in all the classes you derive it from. Anyways, aside from that. KDE is nice, but it's way too slow. Put comparitively, installing RedHat or Debian with KDE2, and Win2k with MS Office for eg on the same box (p2-400), and Windows blows KDE away for speed. KDE is so slow it becomes unusable. I dont want to have to wait 30 seconds just for my freakin file manager to appear. I'd rather open a shell and do it manually than wait - but then whats the point of KDE. Sure, I thought linux was meant to be faster/more stable than windows. Not in my world.

Re: Focus on speed now - ac - 2002-01-19

Okay, now you're just flipping. 30 seconds to start Konqueror on a P2-400? Please. My konqueror appears almost instantaneous on my computer which is much less beefy than a PII. Its only a Celeron, and KDE is just heaven on it. Don't blame KDE for something *you* are doing wrong please. Quite obviously you don't understand the importance of virtual functions either, do you. Can you say super-casting? Maybe reading books meant for dummies isn't such a good thing, huh?

Re: Focus on speed now - Ian Reinhart Geiser - 2002-01-19

MFC... is that really C++? no... At any rate virtual tables add some overhead, just like funcitons add overhead to C. Really it is the compilers job to make the code run faster. I would study some more, maby even take a class in compilers, it is interesting stuff, and would help you look less foolish. So in short yes inheritance makes overhead, but then again, if we all wanted to run blindingly fast we would all write raw opcodes, Assemblers add too much overhead ;) Oh btw, you will, on takeing a class on compilers find out why C++ is better than writeing all in raw assmembly... it scales better. All of the code duplication would invite situations for bugs, and bloat the size even more. Cheers -ian reinhart geiser

Re: Focus on speed now - A Sad Person - 2002-01-19

The whole "virtual functions are slow" thing is misleading. Yes, virtual functions are slower then static binding, and should not be used randomly -- but they're pretty much the fastest way of implementing dynamic binding. The only common alternative is the use of switch statements.. But those are less flexible, nearly a bad with respect to pipelining, and quite a bit larger, so they waste memory and potentially put wastefull stuff into instruction cache.. The overhead is also not at all that signficiant -- a few constant-time instructions, even involving a piepline flush, hardly make a difference with respect to interactive performance..

Re: Focus on speed now - zank - 2002-01-19

Is Linux faster then the Windows kernel? I would think so. Is the Windows graphic shell faster then KDE? probably. You say that it takes 30 seconds to bring up the file manager and you're still using KDE! With that kind of performance I would wipe it off my harddrive right away. I also wish the performance would be better but it's getting better and it's perfectly usable now for me anyway (PIII 450).

Re: Focus on speed now - Tim Jansen - 2002-01-19

>Virtual functions are gonna give you code overhead. They do reduce the speed >of your code, because you're trying to maintain a vtable of functions >(strictly "class methods") that have been derived from a different source. You're violating the good old 90/10 principle (10% of the code spents 90% of the time). Rewriting methods that are called once won't get you anywhere. Like all other low-level optimizations you are only wasting time (and obfuscate the code) unless you concentrate on the hotspots. And even there it is rather unlikely that virtual methods are the cause, unless you have tight-innerloops that frequently invoke them. Especially the startup delay won't change by doing any optimizations in KDE, it's a problem of runtime-linking. And BTW most programmers are too lazy to add the virtual keyword for methods that do not need it anyway.

Re: Focus on speed now - Aaron J. Seigo - 2002-01-19

if you are really a C++ coder you should look into a career change. or at least start using a language you understand better. in the email thread that was referenced they were talking about classes that use copy-on-write ref counted memory to make passing objects by value cheap. it is not as cheap as passing pointers since you will still have the overhead of the ctor and refcounting, but try assigning a QString to another QString several thousand times and see how quick it is. however, as fast as it is, it isn't quite as fast as using plain pointers. that is what they were talking about. nothing about virtual methods. and what is this shit about "put a virtual method in a base class and you are forced to include it in all the classes you derive it from"? i suppose you meant "derive from it", and i also think you were confused and thinking about pure virtual methods. virtual methods don't give you any more overhead than regular methods (which also get inherited. shock, shock!) when the linking can be done at compile time. it is only when you take advantage of features such as polymorphism that force run time linkage that you incur a performance penalty (beyond what is normal for a function/method call), and even that isn't a huge issue. vtables aren't exactly memory intensive either. no, it isn't the use of virtual methods that cause horrible slow downs, though they do have a small cost. on that note, it is often quite practical to use a virtual method as that often saves development time and, used correctly, can even streamline your runtime operations. as for konq taking 30s to start, please try a properly built set of KDE binaries from a recent release. i would suggest something like 2.2.2 by SuSe, Redhat or Debian. they all do quite good with their builds (as does fbsd, apparently). also note that virtual methods or no, the start up time issues have to do with the linker and shared libraries. i'm still wondering if you are a really clever troll or just a moron who thinks he's a coder.

Re: Focus on speed now - Jörgen S - 2002-01-19

Templates and inheritance combined can give you the same flexibility as virtual functions and no extra overhead. What you loose is object polymorphism. It's a tradeoff: 1) Either you go with object polymorphism, thus using vtables or 2) You go with templates using "recurring" inheritance and inlining 1) can give you a tremendous flexibility and extensibility at runtime. The price is speed. But who, cares, buy a bigger machine. If you have a smaller machine, then run a simple window manager or checkout KDE 1.0/Gnome 1.0 or something from CVS and run that. 2) can give you blistering execution speeds which is in some cases faster than C. The price you'll have to pay is memory usage. But then again, buy some more ram sticks. You always have the KDE/Gnome 1.0 option. Software is in symbiosis with hardware. When hardware gets better, then software tend to utilize the extra boost to do something useful. It's a fact of life. Deal with it. I suggest that you should probably read up on C++ before starting to bash out on people. Obviously, the guy you bashed, probably read a couple of more books than you have...

Amazing - a.c. - 2002-01-19

Microsoft has taught a whole generation of very bad concepts. If you really want speed, then don't worry about the language. worry about the algo, which is exactly what was happening. MSFT has built lousy software for such a long time, that ppl are buying into it. Next, you will be saying that Linux/BSD/Unix need to start worrying about security by using Microsoft products.

Virtual Functions - Eean - 2002-01-20

Virtual functions are useful for many reasons. I guess your C++ for Dummies book doesn't really cover OOP. To tell you the truth, I have a hard time with some of the more advanced parts of it. But at least I am aware of where I'm ignorant. I can see, however, where virtual functions make coding easier. This leads to less bug-prone and easier to maintain code. It is a constant trade off. KDE would probably be easier to maintain if it was say, written in Python. But that wouldn't be a good idea (though in 5 years from now when computers are unimaginably fast - who knows?). KDE could have been written in assembly, but that would also be a bad idea.

Re: Focus on speed now - Aaron J. Seigo - 2002-01-19

1) the developers have not been rushing kde3 out the door 2) many of the developers have been concentrating on performance issues 3) start up performance is due to the gnu linker. gnu ld is not part of the kde project. the kde team can not do much about it, though they have helped out the gcc team wherever possible. stop blaming the kde hackers for a weakness in gcc. 4) the speed up bero talked about was not based on any sort of actual benchmarking, it was just a number he pulled out of the air based on an educated guess. 5) bero wasn't talking about virtual method usage, he was talking about things like copy-on-write shared memory based classes being passed about 6) polls of users are nice, but they rarely tell the developers things they didn't know, nor do they often result in one of those users going, "hey, you know what, i'm going to help make something happen." perhaps i'm just bitter tonight. or perhaps seeing the same wrong-headed things said over and over again (though i understand how people arive at those concepts) just gets exasperating after a while?

Re: Focus on speed now - Johnny Andersson - 2002-01-19

I totally agree. This discussion is *old*, and a certain percentage in a certain poll doesn't make something happen.

Re: Focus on speed now - lanbo - 2002-01-22

I am not a KDE developer. I wouldn't like to critizise the job of the KDE developers but I found sad that you blamed gcc. Why? It's simple: You developed a product (call it A) using some other (call it B). When developing A you should know the weekness of B. If A is bad due to B it's your fault for having used it. Remember KDE 1. This was fast! Maybe you should have use C instead? Ok, let's say that C++ is nicer than C. Then just accept that KDE is slow because you decided it to be but not because of the gnu linker. Don't critisize gcc the same way you don't like KDE being critisized.

Re: Focus on speed now - Evan "JabberWokky" E. - 2002-01-22

I am a developer (albiet not a KDE developer). There are two problems with what you are saying. When you design a project, you use tools. When you then profile the project, you find where the slow spots are. It is perfectly reasonable to honestly say: "A big slowdown in launch speed is due to this tool". The second problem is that the KDE project does not deliver anything but source. Any C++ compiler on any POSIX/X based system should be able to compile the entire environment. Effort has been made to make it work with the Solaris compilers from Sun, and on many OSes like AIX, BSD, Linux and Solaris. So it's more like: "Hey, we built this blueprint for a widget. You can use wood or steel. If you use wood, we've noticed it can catch on fire." GCC is not the only compiler used to compile KDE, but pointing out (and trying to fix) it's weaknesses is perfectly reasonable. -- Evan

Re: Focus on speed now - Guillaume Laurent - 2002-01-19

> certain C++ features that have huge overhead. (Virtual functions IIRC) The overhead of virtual functions is barely measurable (check "The C++ Object Model", by S. Lippman).

Re: Focus on speed now - Ian Reinhart Geiser - 2002-01-19

>The overhead of virtual functions is barely measurable (check "The C++ Object Model", by S. Lippman) oh now you did it, you actually sited an actual source containing valid facts... just for that you should be kicked off of the dot ;) I think the largest problem with C++ is the fact that old school ignorant C and VBasic developers try to code with it. You cannot write efficent C++ with a C style. I have seen this in numerous clients code bases. The only thing C++ about them is the compiler. OOD and C++ are like any tool, they can be made to suck if you do not understand them. Either way, I have seen how well KDE/QT scales, and how well motif scaled. This is a reason why I reccomend QT over MFC and Motif now. Cheers -ian reinhart geiser

Re: Focus on speed now - anonymous - 2002-01-19

> Wouldn't it really be nice if <b>all</b> the KDE hackers, before rushing out > KDE3, would spend and additional two weeks (or even a month) just addressing > performance issues. Working on performance issues is an extremely tedious work. It requires a lot of knowledge about the overall architecture, it requires huge amounts of time, preferably a really fast machine to make gprof enabled builds in reasonable time and a certain amount of knowledge about code generation and how C++ code gets translated. Most KDE hackers work on KDE in their free time. They do it because it is fun, because it possibly even allows them to relax from some other work. But often the free time is limited. That is why most often the main thing that counts when hacking is to get it working. It is certainly not fun to sit down, make a gprof build, run applications, make profiling test cases to find out where performance issues are, study other peoples code, etc. It is not something you can enforce (that's how I read your statement) on people. You have to motivate themm to do it. If it's not combined with fun few people are going to do it in their free time, no matter how many polls are being made and how many users complain on lists. They better get down and dig into the code to help out!

Tabbed browsing is the wrong approach - Eloquence - 2002-01-18

I think it's a mistake to include tabbed browsing support in Konqueror. Don't get me wrong -- tabbed browsing is great, but it is not the kind of task that individual applications should handle. Currently Konqueror windows are summarized in the taskbar -- the taskbar could just as well create a repositionable list of Konqueror windows that becomes visible as soon as you click the Konqueror main task in the taskbar (which would be the last window selected, or the first window in the order). This way, any application with many windows (e.g. multi-windowed e-mail, news, FTP, IRC ..) would be able to utilize this feature if the user wants it to, whereas the application developers would save a lot of time. Certainly it would also be possible to do this in a "tab-like" fashion, although this may be trickier than using an additional taskbar the content of which changes when you select an application that has multiple windows. I've submitted this as a wishlist item: http://bugs.kde.org/db/34/34981.html

Re: Tabbed browsing is the wrong approach - Matthew Kay - 2002-01-18

Personally, I would disagree. I sed galeon for awhile (though currently I am using Konqi), and the one feature I desperately miss from Galeon is the tabbed interface. Since Galeon and Mozilla both have tab support, I think that Konqi should have this too -- and that, if you don't want it, or want it in a different way, this is something that should be "yet another option".

Re: Tabbed browsing is the wrong approach - Mauro - 2002-01-18

I like tabbed browser! I'm using Opera 'til Knoqui doesn't support it! please hack it for us!:) tanx Mauro

Re: Tabbed browsing is the wrong approach - Jon - 2002-01-19

So you want something like PWM? http://www.students.tut.fi/~tuomov/pwm/ PWM is a tabbed window manager - each window can have lots of clients running in it. See http://www.students.tut.fi/~tuomov/pwm/screenshots/pwm-2.jpg for an example.

Re: Tabbed browsing is the wrong approach - Eloquence - 2002-01-19

Wow, someone actually understood what I wrote :-). Thanks for the link, PWM is interesting.

Re: Tabbed browsing is the wrong approach - Aaron J. Seigo - 2002-01-19

why would it be a mistake if it is configurable abd you can turn it off? in fact, it will probably be off by default. if you don't like it, it won't get in your way. some people really DO like it though (i'm not one of them) and so will be happy to have the option to take advantage of tabbed browsing/file management. so don't worry, be happy.

Re: Tabbed browsing is the wrong approach - Carbon - 2002-01-19

He's not saying he doesn't want it, he's specifically saying that he just wants it implemented in a way that allows for expandability and use in multiple applications.

Re: Tabbed browsing is the wrong approach - Aaron J. Seigo - 2002-01-19

aaah... i just reread it again and i think i see what he's asking for: extending the taskbar so it can be configured to just show one "tab" for each window of the active application ... this is already pretty much how i use the taskbar with task grouping turned on (though of course it also shows all the other windows too). i think one of the strengths of tabbed browsing is that it puts this interface directly inside the application's UI so it is within easy reach of the menus, toolbars, etc ... it also means you don't need to switch the whole window nor move your mouse very far from the application itself, which can be a big win if you don't run the app maximized or have a taskbar at the top of your screen. *shrug*

Re: Tabbed browsing is the wrong approach - Rakko - 2002-01-21

I love that idea, and have been wanting something like that for quite some time. I recently read an old article on OS/2's Workplace Shell, which had a similar feature, and it got me thinking about it again.

Re: Tabbed browsing is the wrong approach - David Faure - 2002-01-21

I think the main points in tabbed browsing are: * to save resources by sharing the same window * to minimize mouse movement required to switch between sites in the same window * to minimize the number of entries in the taskbar, and the number of windows - no need for any of that window switching, it's all in one. Your suggestion (which looks very much like the already available task grouping!) doesn't address either of those requests.

For a common tabbing approach - Alain - 2002-01-22

I think that tabbed sub-windows are very interesting for Konqueror, but it is also interesting for each multi-sheet program. For Kate (already here), KWord, KSpread (already here) and so... even KMail, KNode... And it would be possible to create in the same way these tabbed sub-windows... It would be very innovating and powerful... What would be also very powerful is the ability to create taskbars in every app in the same way, creating buttons from ANY command of the menus. It was made by a fantastic program in Windows 3.1, a shareware called Superbar (buttons had one icon or one text or icon + +ext). Perhaps it would have been a good idea for KDE 2, now I fear it is too late...

Re: Tabbed browsing is the wrong approach - hank - 2002-08-26

I believe another benefit of tabbed-browsing really becomes evident when on a slow or error-prone connection. For example, when doing queries in a search engine, I can quickly scan through and load all the pages I might want to investigate more deeply into. While I'm reading the first, the rest are loading. The best part is it can be configured not to focus/raise the windows. But I see the point in doing this at the window manager level. Sawfish is the closest thing I can find, so far, which does just what I explained. If I want a window to have focus, I want to tell it to do so. Even certain dialog boxes annoy the hell out of me when I'm typing and they pop up. Two features I'd like using: 1. Window doesn't get focus unless I tell it to. 2. Window is created at one level lower of the focused window. Gnome consolidates windows into one icon when it sees fit, I'm happy with its judgement. I'd hope that multiple windows of the same application share resources. Unless they're all running java... I don't forsee a problem with having more than 100 or so open. Perhaps you could run many more in a tabbed environment, but who cares at that point?

Re: Tabbed browsing is the wrong approach - Christian Reis - 2002-07-03

Please, don't do this to Konquerer. UI developers have been arguing over MDI for years now, and the conclusion has _always_ been (Read Alan Cooper's work. Read Nielsen's surveys. Read any UI expert's comment on MDI) that MDI is a broken concept, and that users can't handle it properly. Beyond that, it adds navigational and operational complexity. There is no need for us to main Konq's interface by adding a feature that _should be provided by the WM_. The _window manager_ is responsible for handling window placement. If you think accessing windows in a tabbed fashion is convenient (and it is, of course), look for a window manager that supports this feature. Ion and PWM are two great examples of WMs that do. Oh, sure they lack features. Probably a lot _more_ good would be done spending time working on getting them up to speed than hurting Konq. Mozilla suffers from tabs (though not horribly, yet, because we don't have an end-user market share), and we are only beginning to see problems caused by the confusion it creates. It's just a sticky pit of UI hacks now that it's in. Want an example? http://bugzilla.mozilla.org/show_bug.cgi?id=108973#c45 Horrible. Don't let this happen to you.

Re: Tabbed browsing is the wrong approach - Benjamin - 2003-02-07

Huh? Your example is broken. The bug is about being able to lose all tabs in a window by a simply keystroke or click. The comment is about a strange suggestion as solution. Just because ridicilous solutions for a simple bug are discussed does not mean the behaviour is too complex. The simple solution is to pop up a window and ask for confirmation (which is the main suggestion in this bug). Image KDE had a method to quit by a click (it has). Imagine that it would quit without asking beforehand (it does not, it asks you how to proceed). You could lose all the state of all your windows on your desktop. Image somebody suggests a ridicilous solution for that. Does that make the concept of Windows in KDE overly complicated? No. So doesn't the example you posted for Tabs. Even if tabs would be complicated, there is no reason for users to suffer as you like to say. All people I know which don't like tabs, just don't use them. Easy as that. That said, yes, tabs should be handled by the window manager, presumed I can still have all the comfort that direct support by the applications gives me (easy keyboard switching, drag and drop, creating new tabs, and so on).

Re: Tabbed browsing is the wrong approach - Matthias Trevarthan - 2002-08-02

Hmmm... I'm not sure how old this thread is, as it doesn't give yearly timestamps, and the one gentleman mentioned KDE2, which is now being replaced. However, I have an opinion on the matter. I LIKE tabbed browsing. I LIKE tabbed Konsole. The ability to add another window, within the current window, and switch between said windows with a keystroke is very useful and efficient. I hate how the current setup works on window architectures. Windows never seem to open up the same size, and there is little hierarchy between windows of the same application. (ALT-TAB just doesn't do it for me...) (although I admit that KDE attempts to change this with the current taskbar) Isn't UNIX all about efficiency anyway? I mean, honestly, if I wanted to point and click all the time, I'd run a Microsoft box. (And what's up with everyone assuming KDE only runs on Linux?) As for issues regarding implementation: (window manager vs. application) I believe it would be slick to implement this in the window manager itself. That way the feature is always available to all applications. However, I don't think multiple WINDOWS need to be opened by the window manager. I think the tabbed architecture needs to be standardized in the base class of a window itself. I would think this would improve resource consumption. Again, this may be a really really old thread, but I just thought I would chime in with my two cents. Matthias Systems Administrator, C/C++, Java, Graphics, PHP/Web Programmer, and Unix Enthusiast.

Re: Tabbed browsing is the wrong approach - Gnome User - 2003-01-04

Don't you feel stupid now.

Outdated information about Debian KDE packages... - Kamil Kisiel - 2002-01-19

Last time I talked to Chris Cheney, the future KDE3 maintainer for Debian, he informed me that due to lack of time, Daniel Stone will not be able to maintain the KDE2 packages. It appears that for now Chris will be maintaining both.

Document/File Menu entry: send document - Markus Heller - 2002-02-20

Here's a good feature I saw when looking over by boss's shoulder (he uses windows): In Excel you can just send the document you are working on to somebody else. Why don't we implement this feature in all KDE applications which process singular files? I imagine all of the KOffice applications could increase usability with such a feature. Let's say, KWord links to KMail, registering the KWord-document as an attachment to an Email. This functionality would be applicable to KPim-related tools and many more... Regards, Markus