Re: KDE 2.0 impressions
- From: "Padraig O'Briain" <Padraig Obriain ireland sun com>
- To: gnome-private gnome org
- Subject: Re: KDE 2.0 impressions
- Date: Tue, 31 Oct 2000 16:14:41 +0000 (GMT)
I have read with interest the discussion about KDE and GNOME performance. As I
work for my employer my interest in performance has hitherto been focussed on
CDE and StarOffice performance on Solaris. I am now, of course, interested in
GNOME performance.
As Matthias notes, the RSS values give us no idea about the memory usage. Does
Linux have a command similar to the pmap command on Solaris? This would give us
a view of how much of the process size is shared between processes. Although
interesting, I do not think that this has much impact on startup time for
applications. I am assuming that a non-memory constrained world although I
realize that some people do not inhabit such a world.
One of the things that we found on Solaris which improved startup performance
for applications was the use of scope mapfiles. I have not seen these used in
GNOME so perhaps scope mapfiles are not available on Linux. Could someone
educate me on this point? One can think of a scope mapfile for a shared library
as being similar to a .def file for a Windows DLL in that it defines the
interface provided by the library, i.e. the functions in the library which can
be acccessed outside the library. The problem with a shared library is that, by
default, i.e. without a scope mapfile, every function in the library is exported
but in Windows the default is that no functions are exported.
If using C++, the function names, those mangled ones, tend to be even longer
than the function names used in C and the improvement in startup time from using
scope mapfiles for the shared libraries for a large C++ application, i.e.
StarOffice was significant. The size of the symbol table reduced significantly
which reduced the cost of loading it and the cost of finding external references
was reduced as the symbol tables were smaller. It is worth noting that external
references are to symbol names, without the shared library which contained them
at link time being specified. On Windows external references are to a reference
number in a specific Windows DLL. This makes fixing up references much faster
on Windows although if someone changed the order of the functions in the DLL
since your application was built you will have some problems.
Solaris also have a feature which allows the code in shared libraries to be
reordered at link time so that frequently accessed code is clustered together
and code which is very infrequently used is at the end of the file and is never
paged in. Windows also has a similar feature for DLLs. Use of such a feature can
reduce the working set size and paging activity for memory constrained systems.
This feature was invaluable when trying to get CDE performance to an acceptable
level on 32 Mb systems.
Another feature which is the default on Windows and is available as an option on
Solaris and I do not know its state on Solaris is to load shared libraries only
when required rather than automatically on startup. This can make a significant
difference to the user-perceived startup time if not all shared libraries have
to be loaded before the user perceives the application to have started.
It is not clear to me whether there is a performance problem on GNOME but if
there is, hopefully, we have the tools to fix it.
Padraig
> Delivered-To: gnome-private gnome org
> To: gnome-private gnome org
> Cc: gnome-hackers gnome org
> Subject: Re: KDE 2.0 impressions
> Mime-Version: 1.0
> X-Markus: It's not Markus, it's Matthias, Matthias Warkus
> X-Sender: 340092246204-0001 t-dialin net
> X-BeenThere: gnome-private gnome org
> X-Loop: gnome-private gnome org
> X-Mailman-Version: 2.0beta5
> List-Id: <gnome-private.gnome.org>
>
> (I'm trying to move this to gnome-private as gnome-hackers is shutting
> down AFAIK.)
>
> +++ Sat, Oct 28, 2000 at 12:25:47PM -0400 +++
> Miguel de Icaza e-mails me. Film at 11. Reply right now, after the break.
> >
> > > Of course one can argue that this is due to the fact that KDE 2.0
> > > hass even the smallest of applications link to the object model
> > > stuff and such; most KDE applications are approximately of the same
> > > size. This might mean that they share more code with each other
> > > than GNOME programs do, however.
> >
> > Someone told me --and I have not been able to verify the actual code,
> > but it seems to be true-- that some startup program actually links
> > with all the libraries in KDE and when you launch another KDE app,
> > this process just forks and dlopens the new application.
>
> Yes. The program is called kdeinit.
>
> > Something that might be an interesting task is to restart the computer
> > and immediately run KDE, and check the available free memory. And
> > then do the same for GNOME.
>
> I'll do that tomorrow, for now here's a ps aux both from a fresh KDE
> 2.0 and a fresh default GNOME 1.2.x setup (i.e. GNOME started with
> .gnome directory removed):
>
> Fresh KDE 2.0:
> USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
> mawa 4528 0.1 8.9 14816 5644 ? S 00:41 0:00 kdeinit: dcopserver
> mawa 4530 0.0 9.7 14948 6168 ? S 00:41 0:00 kdeinit: klauncher
> mawa 4532 0.9 15.0 16244 9520 ? S 00:41 0:00 kdeinit: kdesktop
> mawa 4534 0.1 9.4 14784 5988 ? S 00:41 0:00 kdeinit: kded
> mawa 4538 4.5 4.1 3644 2616 ? S 00:41 0:01 artsd -F 5 -S 8192
> mawa 4544 0.1 9.5 14868 6052 ? S 00:41 0:00 kdeinit: kxmlrpcd
> mawa 4546 0.0 8.9 14816 5660 ? S 00:41 0:00 kdeinit: kio_file
> mawa 4552 1.5 14.7 16504 9340 ? S 00:41 0:00 kdeinit: kicker
> mawa 4554 0.3 11.9 15040 7564 ? S 00:41 0:00 kdeinit: klipper
> mawa 4556 0.1 10.4 14856 6612 ? S 00:41 0:00 kdeinit: khotkeys
> mawa 4558 0.0 8.2 14616 5240 ? S 00:41 0:00 kdeinit: Running...
> mawa 4560 0.2 11.0 15072 6952 ? S 00:41 0:00 kdeinit: kwrited
> mawa 4563 0.7 11.2 14288 7084 1 S 00:41 0:00 knotify
> mawa 4567 0.7 8.6 11188 5460 1 S 00:41 0:00 ksmserver --restore
> mawa 4569 0.7 12.0 15392 7604 ? S 00:41 0:00 kdeinit: kwin
> mawa 4571 0.1 10.7 15056 6812 ? S 00:41 0:00 kdeinit: kcookiejar
> mawa 4572 2.1 13.2 15656 8396 ? S 00:41 0:00 kdeinit: konsole
>
> Fresh CVS GNOME 1.2.x:
> USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
> mawa 4620 0.8 5.7 5992 3648 1 S 00:42 0:00 gnome-session
> mawa 4631 0.1 2.9 5300 1848 ? S 00:42 0:00 gnome-smproxy
--sm-cl
> mawa 4635 3.0 4.9 4480 3096 ? S 00:42 0:01 sawfish
--sm-client-i
> mawa 4640 0.1 0.6 1044 428 ? S 00:42 0:00 esd -nobeeps
> mawa 4680 2.9 8.1 7928 5144 ? S 00:43 0:01 panel
--sm-client-id
> mawa 4682 0.2 2.4 2784 1520 ? S 00:43 0:00 xscreensaver
-no-spla
> mawa 4686 0.1 1.9 2400 1204 ? S 00:43 0:00 gnome-name-service
> mawa 4690 1.2 5.9 6988 3748 ? S 00:43 0:00 tasklist_applet
--act
> mawa 4692 3.0 6.1 7136 3872 ? S 00:43 0:00 deskguide_applet
--ac
> mawa 4697 1.1 5.7 6208 3660 ? S 00:43 0:00 battery_applet
--acti
> mawa 4701 4.1 6.3 6308 3980 ? S 00:43 0:00 gnome-terminal
--use-
> root 4703 0.2 0.6 892 436 ? S 00:43 0:00 gnome-pty-helper
>
> The KDE RSSes are significantly larger than the GNOME ones. Simply
> adding the stats up won't do much good since there's a lot of page
> sharing going on, especially on the KDE side. However, I think it's
> safe to say that GNOME consumes at least a little less memory --
> witness the SIZE and RSS of Kicker compared to panel.
>
> mawa
>
> PS: Speaking of GNOME's new default settings, which I saw for the
> first time doing this comparison: It's a bit uncomfortable to install
> a battery status applet by default; on a desktop machine, it
> immediately reports "battery low". Maybe the user should make a choice
> about what kind of machine they run when starting GNOME for the first
> time?
> --
> It's not whether you win or lose, it's how you place the blame.
>
> _______________________________________________
> gnome-private mailing list
> gnome-private gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-private
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
