This is a brief introduction to Gnome optimization, both the hows and the whys. Details of individual tools and techniques are left for later articles, but a collection of hints and tricks is provided. Update: GNOME 2.10 Beta 2 is the first pre-release intended
for wide public scrutiny before the final release.
Introduction to Optimising GNOME Apps; Gnome 2.10b2 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Nice article.
My goodness. I don’t think you read the tittle at all. It’s an “Introduction…” With more to follow. Let wait and see before you start taking pot shots.
I love Gnome. Anything to make it an even better experience then it is, is worth my time to read.
Many CPU-intensive library routines have already been optimized.
I wouldn’t count on it. In fact if you look at the GLibc README it actually [u]says[/u] that they haven’t paid particular attention to hunting for optimisations (In their case I completely understand why) and GLibc is used all over the place.
GNOME 2.10 Beta 1 was announced just 8 days ago.
Too fast? Not for testers, no way! Gotta beat those bugs back!
Installed 2.9.91 via ubuntu tonight, apparently gnome-vfs has a new bug now and it would not connect anymore to samba shares that don’t require password (it insists on the user to provide a passwd). I filed a bug report at gnome.org earlier.
It appears one of the main pushes with this release was getting as many bugs sqaushed as possible. I’m really looking forward to the results, as gnome is quite stable, but has some rough edges. Overall I think this is a good focus for this release, get the fancy features in next release.
ot, but it seems mr, Mckenzie can’t decide which spelling to use: british or american.
so he mixes both of them…
Are there any plans to integrate GNUStep framework right into Gnome? Perhaps a new backend for GNUStep should be written for native GTK look and feel.
Startup times of some Gnome Applikations are insane. For example, when I start GEdit it takes 3 seconds, but starting blender.org requires just 1 second.
Is there any good reason why a simple plain text editor starts so much slower than a complex full featured 3D- construction and rendering application?
Yes. That’s because gtk and most gnome libraries are not optimized at all. In this specific example, Blender only requires 4-5 shared libraries to pre-load, while any normal gnome apps requires between 18 and 24. There is obviously an architecture problem as well as an optimization one. Hopefully, the Gnome developers will optimize gnome to use less memory and fee faster, soon. It’s not a glamorous work, but it’s a needed one.
It’s not a glamorous work, but it’s a needed one.
i see time wasted every month on little features that are just useless to you, me and the general user. those dont help the average business user either, or *cough* *fanfare* large scale deployment yadda dadda.
GNOME seems fast enough for me, what is everybody complaining about.? An editor starting up in 3 seconds as opposed to one? Are you for real? Anyway, the 2.10 series of GNOME seem to be very fast. I have a 1.4GHz Athlon with 256MB of RAM and I am experiencing some speed improvement. The menu seems responsive now. But I never really took the GNOME/GTK is slow folks seriously to begin with.
someone started to adress the slowness that is GTK+ (and on top of it Gnome)!
http://shots.osdir.com/slideshows/slideshow.php?release=234&slide=1
GNOME is SLOW.
It has been said time after time but never was reported any work being done on speeding it up. Finally there is an guideline, so thank you Callum McKenzie for writing that article, it was needed!
gnome isnt slow, gtk gui stuff can be unresponsive though, and thats what gives users the “slow” impression.
>Are there any plans to integrate GNUStep framework right into >Gnome? Perhaps a new backend for GNUStep should be written for >native GTK look and feel.
Probably not. What do you mean by integrate?
Perhaps rewrite GnuStep using Gtk widget set and targetted for the Cairo display?
-D
Perhaps rewrite GnuStep using Gtk widget set and targetted for the Cairo display?
You don’t need to rewrite GNUstep (Yes, that’s the correct spelling) to achieve the second, it’s already in.
Apart from that, I don’t see any advantages that integrating GNUstep with Gnome could bring.
An editor starting up in 3 seconds as opposed to one? Are you for real?
What do you mean?
I tried here too, and it takes 3 seconds too. And i’ve got a pretty nice machine; and Athlon2000+ 256MB.
And that’s because i’ve got almost no apps open right now; when i have more it takes “ages” openning a simple text editor (swaping, swaping… btw, my HD is 7200 rpm), which always makes me feel terribly embarrased when there’s someone next to me.
It’s a fact. No matter how you twist it, it’s a fact: Gnome could and should be faster. Especially apps-startup, that’s the main problem.
Victor.
I tried here too, and it takes 3 seconds too. And i’ve got a pretty nice machine; and Athlon2000+ 256MB.
Took less than a second in my Athlon 1800+.
Haha! GNOME is slow because an editor takes 3 seconds to launch! You guys crack me up! Woops, 3 seconds of my life gone.
I use XFCE-4 and it’s all GTK2. It’s damn fast, so GTK is not the problem. Also leafpad is a pretty fast editor in GTK that starts up just about instantly.
For me GNOME is also slow, that’s why I’ve made the switch to xfce. Anyway, I hope they improve the speed in future releases.
Are you sure it wasn’t 2.6 secondes. I could swear that it’s 2.6 seconds, that’s a fact!
Oh wait, now it’s 2.1 seconds. What’s going on?????
Are these optimizations specifically for the gnome libraries or are they optimizing gtk too? I use both on my home PC, but use only gtk and a gtk based window manager on an old laptop, so any optimizations on gtk would be excellent for me.
” gnome isnt slow, gtk gui stuff can be unresponsive though, and thats what gives users the “slow” impression”
Ah, gnome is not slow, but GTK is.
I always thought Gnome=GTK. But if not, maybe it’s time to build Gnome on QT.
Are you sure it wasn’t 2.6 secondes. I could swear that it’s 2.6 seconds, that’s a fact!
Oh wait, now it’s 2.1 seconds. What’s going on?????
and
Haha! GNOME is slow because an editor takes 3 seconds to launch! You guys crack me up! Woops, 3 seconds of my life gone.
Why the joking? Do you think 2 seconds is fine for opening a text editor? It shouldn’t take not even a second, it should be as fast as i blink my eye.
And of course if open gedit many times the startup time will be shorter because it’ll have lots of cached stuff.
And i don’t mind wasting 3 secs of my life, but you bet it’s damn embarassing. “Look, a notepad takes 3 seconds to open on linux! I’m not gonna use that crap!”.
Victor.
I always thought Gnome=GTK. But if not, maybe it’s time to build Gnome on QT.
funny logic…
you don’t know why the gnome folks are using GTK instead of QT, do you?
“And i don’t mind wasting 3 secs of my life, but you bet it’s damn embarassing. “Look, a notepad takes 3 seconds to open on linux! I’m not gonna use that crap!”.”
Except gedit is not a notepad. Syntax highlighting, auto-indent, plugins, MDI, etc. etc.
gedit shouldn’t be compared to notepad. It has much more features (e.g. syntax highlighting). I’d wager that a strict gtk2 notepad clone with just a text field and a main menu would take no more than a second to start.
A lot of the Gnome libraries are being marked as deprecated as more and more Gnome comes to depend just on gtk (as more functionality is moved into gtk).
I have no problems with Gnome’s speed on my system. I suppose I’m just far more patient than most people here, and can stand even a 3 second start up. If you open multiple documents in gedit, the additional documents should open as fast as your hard drive can access and load them, as gedit is still running, and is in Ram.
Please tell me why the gnome folks are using GTK over QT.
My point is: Gnome always has an excuse for it’s slowness. If it isn’t GTK, then it’s is PANGO, or the framework below that, whatever.
The very first beta reviews talk about KDE3.4 being faster. That’s something we don’t hear about Gnome. To me personally I really like Gnome being smoother, better designed than KDE, but I really hate it’s slowness and whatever excuse is invented everytime. It is SLOW SLOW SLOW.
Except gedit is not a notepad. Syntax highlighting, auto-indent, plugins, MDI, etc. etc.
Yeah yeah yeah, i’ll make sure when i’m here embarrased to say “ah, but you know… it takes time to open because it’s got some features like, code highlighting”…
And the person will say “uh? what’s code highlighting?” and i’ll say “oh, nevermind… just trying to explain why gedit takes lots of time to open… you know, it’s not really slow, you know? The next time it will open faster… you’ll see…”
I’m sure it’ll make me feel less embarrased.
Victor.
on my dorun 700 MHz, KDE works much slower than GNOME, I don’t know what do you speak about
Gedit is not a replacement of notepad but -as the name says- an editor. It does not make any sense comparing the two. Features like syntax highlighting are usefull and I sure don’t want to lose them just to get a faster startup!
Now, if you want a fast loading notepad clone, leafpad is what you’re looking for. It’s a great application that loads in an instant. And since it’s actually the 13th most popular app on gnomefiles.org, I would assume that those 3 seconds do matter…
But I don’t see this as an issue with gedit or even gnome in general.
Then gedit is slow. Take leafpad which is also a gnome app and it starts up in the blink of an eye.
So to claim that gnome is slow because gedit takes 3 seconds to start up is retarded.
And yes, I think gedit’s features might have something to do with it starting up so “awfully” slow (About 2 seconds on my machine, btw.)
I’ve recently switched from windows to linux full time (almost, still drop by windows to play games sometimes) and trying both KDE and GNOME I stuck with the latter (after “the ubuntu experience”).
I have never been bothered by speed issues in either, but then again I use my computer for doing work and not timing how fast some app opens. If you do the latter I suggest you get a life, or something.
Of course GEdit is much more than a lightweight notepad.
Thats why I compared it to blender, which is a full featured 3D-Application starting in a third of Gedits time though it has 10 times more functionality.
Blender proves that startup in less than a second is even for large applications possible.
first off, gnome != gtk. gnome is a dm, gtk is a gui toolkit.
i didnt say gtk was slow, i said it was unresponsive. stuff like slow repaints give an impression of a slow app, even though it may not be.
is the 3 second start of gedit from kde? because the gnome libraries will all have to load, which would account for it taking a long time to load. same deal with using kde apps in gnome, one of the reasons i avoid using them.
the reason gnome uses gtk is that it was created as a free response to the propriatary(at the time) qt. as it was a free response, the choice was made to use a free language which is why c is used over c++.
gtk has been getting faster(albeit slowly 😉 ), and it will be way faster in gnome 3. if you havnt heard that, you havnt been listening in the right places.
anyone who thinks gedit and notepad are similar really need to look at the apps again. for what it does, 3 seconds is quite acceptable.
—————————–
honestly, i dont understand what people’s problems are with gnome. its slow, yes, but not unbearably, and not too bad when you take into account the amount of functionality. kde can only be called fast in comparison to gnome, and even then its not by much. where kde beats gnome hands down is its load time. but first of all, how often do you load your dm? i do once to twice a day. an extra half minute isnt something im exactly going to get worked up about.
where you will get the perception of slowness is with the crappy gtk repaints, which is only made worse if you have a cruddy vid card, or are using the vesa drivers. but an unresponsive ui does NOT mean its a slow app, it means it has an unresponsive ui.
last but not least, be realistic in your testing. i can open nautilus in a very small fraction of the time it takes to load konq(even more if i do it without qt or kdelibs in memory), does that mean that kde is slow? if i were to make that claim i would either be stupid or dishonest.
This is because this type of discussing that gnome become better: too much people to speak about and less to work! We speak all time against someting, but do nothing (a complete waste of time)
What does this article have to do with gnome? Nothing, these are general optimization tips for every kind of programs.
The article includes just one tip that has to do with glib, not even gnome itself.
It should be called: introduction to optimizing apps, or even better, introduction to app optimization
will gnome 2.10 will have a standalone vcard program like contact in OS X? (rubrica is close, but still more a button orgy than a clean and finished app)
Now that they seem to have modified the anoying feature of individual icon locking on the taskbar, I would love to see a “really easy but productive” email client a la OS X (thunderbird dont hold it), a separated vcard programm and to make it perfect – a standalone calendar.
How does they take screenshot with open menu? When I press the printscreen key when a menu is open, the command just do nothing. I have gnome 2.8.2 (gentoo)
For Herr c++. As a python coder, I thanks the gtk team for using c, now I(we) have a nice binding to gnome for a real OO, easy but powerful language.
Gedit is not a replacement of notepad but -as the name says- an editor. It does not make any sense comparing the two. Features like syntax highlighting are usefull and I sure don’t want to lose them just to get a faster startup!
I don’t see how those features could possibly cause the app to take so long starting up. When I start vim (which has syntax highlighting, auto-indent, auto-correction, and nearly every other feature one could want from an editor), it is there. vim [filename], and it’s open. That’s it! Why can vim do this immediately, while your Gedit program cannot? Well, the difference is probably in the libraries that your program links against, or perhaps it’s poorly written, but it’s certainly not true that having a feature-ful editor makes it slow.
comparing gui and non gui application startup times is just silly.
So now we came to a conclusion that Gnome doesn’t have a notepad. I thought Gnome’s focus was in providing a simple desktop to simple users.
Victor.
> So now we came to a conclusion that Gnome doesn’t have a notepad. I thought Gnome’s focus was in providing a simple desktop to simple users.
No. We don´t. gedit provides notepad funcionality PLUS syntax hilighting and so.
Gnome terminal has got to be the most inefficient program known to man. Try running a compile on Gnome terminal, then check top on another window. Gnome Terminal takes easily 50% of CPU time from GCC.
On second thought, don’t. Fire up an xterm or something, it’ll get the job done in half the time. (though admittedly does not look as nice)
is there any difference to say: “Gedit loads in 1 sec, Gedit loads in 3 sec”? C’Mon! give me a break! talk about anything more important. For example, the gnome terminal problem is by far a more important issue.
I just timed Kate and it took 3 seconds to open too!
Xgl seems to really increase the speed of gnome-terminal.
Conventional wisdom (which is often completely wrong) dictates that C programs run faster than C++ programs.
However, there is no question that KDE and it’s apps load faster, run faster, and use less memory than Gnome and it’s apps.
This is proof that C++ can run as fast or faster than C, if useed and optimized properly. It’s also a reflection on the importance KDE developers put on optimization. I rember there was big boost in performance and decrease in memory usage between KDE 3.1 and 3.2.
Gnome developers need to do the same. Although I have noticed an improvement in performance with Gnome 2.8, it still lags behind KDE. It seems that Gnome developers have put more importance on the actual interface (keeping it as simple and intuitive for the user as possible – something that KDE needs improving on).
However, optimization might be a greater challenge for Gnome developers. The reason for this is that GTK+ is based on pure C, and GTK+ is fully object oriented, and thus has led to more complicated code (to approximate OOP, a necessity for GUI programming, which is not natively supported in C). And more complicated code ussually leads to buggier, slower performing code.
By contrast, C++ supports OOP natively, which means that C++ based QT makes the OOP of GUI objects much, much easier and more elegant.
C++ is most certainly a bigger, more complicated, and more difficult to learn language than C. However, it’s greater complexity and richer feature set leads to easier, cleaner, more elegant, and more optimized code. I’d rather have the complexity in the language, than in the code I have to write.
Anyway, that’s just an aside. 😉
At work, I recently did a performance analysis of certain software that use gtk and some things from gnome as well. One thing that stood out was the extremely slow startup times of the applications. Just slow, slow, slow, SLOW! I mean WAY too slow. In closer inspection it turned out that initializing gtk classes is very VERY slow (while creating a new instance is not).
Why is it that I never hear about anyone running some gtk applications through a profiler to find out what exactly is makeing it slow? What functions are supposedly so slow?
As someone pointed out, GNOME-Terminal is unbelievably poor with resources. It just shows that no matter how many eyes open source development can bring, it doesn’t stop people writing sloppy and inefficent code.
Something really needs to be done about GNOME, and also programs like OpenOffice. They’re so slow – they don’t give people an incentive to switch from Windows. I mean, I installed Ubuntu for a curious Windows user the other day, and he wasn’t remotely impressed by the slowness and amount of memory it hogged up.
And I gotta admit, against a well-maintained WinXP installation (eg no spyware, pointless background stuff or theme crap) GNOME is a really bad performer.
What bothers me is that people don’t see the importance of this. GNOME’s developers all enjoy their 3GHZ 1GB RAM boxes (as all geeks should) but there are tens of millions of machines out there, in homes and businesses, with 64 or 128MB RAM. Linux should be an attractive update, but while GNOME/KDE/OOo gulp up RAM they destroy another incentive to switch.
People need reasons. People love speed – look how big the CPU market is, as people rush out to upgrade, in the hope that their systems will be faster.
I’ve seen first-hand users being disappointed by Linux desktop’s speed. I’ve read countless posts all over internet message boards about it. And the same old responses (use gentoo and fluxbox! etc.) are really bad excuses for a fundamental problem.
If the open source community can’t make a desktop OS that doesn’t rival or exceed Windows in bloat and slowness, it’s going to struggle getting past its already tiny marketshare. I hate to say it, and I want OSS to succeed, but it’s true. Without work on this problem, there’s one less incentive to switch.
And we need all we can get.
(For heaven’s sake GNOMErs, stop throwing in quickly-hashed features and think about efficiency!)
bitch bitch bitch
you like to complain dont you?
… it’s about how fast the user gets a certain task done.
”
GNOME seems fast enough for me, what is everybody complaining about.? An editor starting up in 3 seconds as opposed to one? Are you for real? Anyway, the 2.10 series of GNOME seem to be very fast. I have a 1.4GHz Athlon with 256MB of RAM and I am experiencing some speed improvement. The menu seems responsive now. But I never really took the GNOME/GTK is slow folks seriously to begin with.
”
Yes, 3 seconds is a big deal when it’s a high-end machine. The real question is why should the user WAIT for text editor; its not like the gimp.
Fully agreed.
Gnome needs optimizations. That’s much is true.
Watcher, I agree with your post, mostly. Gnome needs to be faster.
However, KDE is improving immensly in that department. 3.2 was a big improvement over 3.1. And the reviews of 3.3 have raved about speed improvements.
In my experience, I get snappier performance with KDE over Gnome. KDE also uses, on average, 40 – 50 megs less of memory than Gnome.
That said, my 300MHz, 228meg memory thinkpad gets noticably better performance running Mandrake with KDE 3.2 and the 2.6 kernel than my eMachines 1.6GHz, 256meg ram machine running WinXP.
So, in short, in spite of Gnome’s relative slowness and the large footprints of both Gnome and KDE, I do believe that Linux gives better all around performance than Windows XP.
Because Gedit isn’t an ordinary text editor, it’s a programmer’s editor. That’s what we’ve been babbling about all day. How many times do we have to tell you how silly it is to compare notepad to Gedit?
Gnome-terminal has seen a lot of improvements in the 2.9 series. GNOME is a lot faster in this series than in 2.8. Menu’s are very responsive, icons are being cached etc. GTK-2.6 has also had several speed optimizations and it’s evident .
To the person who said KDE is less resource intensive than GNOME, that’s a BIG LIE! Not only do C++ apps take forever to compile, they take forever to launch and they consume at least twice as much memory as do C apps.
It is no wonder that the slowest popular apps on Linux are all C++ based. Until recently Konq was so slow to launch they had to provide hacks to pre-load it in memory. The same goes for several other KDE apps. Are you kidding me? The KDELIBS alone is heavier the three gnome libs combined.
The GNOME/GTK+ is slow mantra is false, old, unfounded and misguided. It is even more evident when people have unrealistic expectations of what a fast application is. For example, when people think loading a programming editor in 3 seconds is unbearably slow. Get a life!
To add to the comparisons with Gedit, Xemacs, also a programmer’s editor and based on what used to be a famous example of bloatware, also starts immediately. As Victor says, Gedit just looks foolish.
You hit the nail on the head. GNOME has gotten a whole lot faster in the course of the 2.x series. I installed the latest 2.10 beta a couple of days ago. I actually have done silly stuff like timing(*not* in a scientific, ie. benchmarking kind of way) how fast it has become-things like opening GNOME terminal and cat’ing really large log files and rapidly moving and resizing windows across the desktop. One of the reasons why I found myself doing so is that I was really impressed at how quick certain things had become.
What really surprised me was that stock GNOME-2.10 configured and compiled without any comiler and loader optimizations is faster than what I achieved with both using GNOME 2.8. When GNOME 2.8 came out almost everyone noticed how much quicker it was than <2.6. I then went ahead and recompiled the 2.8 desktop apps using fairly aggressive CFLAGS(nothing too overboard) and using LDFLAGS. This made a noticable difference-I ad never seen GNOME so fast(Ubuntu clued me into using LDFLAGS-thats how they get there speed boosts). But as said when I installed GNOME-2.10 I did nothing but ./configure –prefix=/usr –sysconfdir=/etc/make/make install and I was and am quite impressed with the results. Once the ebuilds for GNOME 2.10 hit portage I will recompile the whole thing with my CFLAGS and LDFLAGS.
At this point I notice fare less tearing and redraw than I have ever experienced with GNOME. GNOME-Terminal is at least 200% faster than it was-using the same anti-alaised fonts in both GNOME-Terminal and xterm xterm only beats GNOME-Terminal by 2 seconds (18.79 vs. 16.33). And that is a marked improvement.
If you look at what libraries are linked in using gedit it’s quite an amazing repetoire:
**********************************************************
ldd /usr/bin/gedit
linux-gate.so.1 => (0xffffe000)
libgtksourceview-1.0.so.0 => /usr/lib/libgtksourceview-1.0.so.0 (0xb7f9e000)
libeel-2.so.2 => /usr/lib/libeel-2.so.2 (0xb7f11000)
libgnome-menu.so.0 => /usr/lib/libgnome-menu.so.0 (0xb7eff000)
libgnome-desktop-2.so.2 => /usr/lib/libgnome-desktop-2.so.2 (0xb7eeb000) libstartup-notification-1.so.0 => /usr/lib/libstartup-notification-1.so.0 (0xb7ee3000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb7eda000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7ec5000)
libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0xb7e39000)
libgnome-keyring.so.0 => /usr/lib/libgnome-keyring.so.0 (0xb7e2f000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7df9000)
libgailutil.so.17 => /usr/lib/libgailutil.so.17 (0xb7df1000)
libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0xb7dd9000)
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0xb7d79000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7d70000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7d55000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c69000)
libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0xb7c56000)
libesd.so.0 => /usr/lib/libesd.so.0 (0xb7c4c000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7b68000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb7b2b000)
libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0xb7acc000)
libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xb7a95000)
libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7964000)
libhowl-0.9.6.so.1 => /usr/lib/libhowl-0.9.6.so.1 (0xb7836000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7823000)
librt.so.1 => /lib/librt.so.1 (0xb781b000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0xb77c2000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7790000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0xb777b000)
libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0 (0xb7775000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb770b000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7706000)
libgnomeprintui-2-2.so.0 => /usr/lib/libgnomeprintui-2-2.so.0 (0xb76d3000)
libgnomeprint-2-2.so.0 => /usr/lib/libgnomeprint-2-2.so.0 (0xb7664000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7630000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7585000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7553000)
libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 (0xb7529000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb73a2000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7391000)
libz.so.1 => /lib/libz.so.1 (0xb7378000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb7350000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7322000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7019000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb6fab000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6f89000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6f73000)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0xb6f6b000)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0xb6f5d000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6f1a000)
libm.so.6 => /lib/libm.so.6 (0xb6ef9000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6eb2000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6eae000)
libdl.so.2 => /lib/libdl.so.2 (0xb6eab000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6e0a000)
libpopt.so.0 => /usr/lib/libpopt.so.0 (0xb6dff000)
libc.so.6 => /lib/libc.so.6 (0xb6ceb000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7feb000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb6ce6000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb6cdd000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xb6cda000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0xb6cc3000)
libXfixes.so.3 => /usr/X11R6/lib/libXfixes.so.3 (0xb6cbe000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0xb6cb3000)
**********************************************************
I count 65 shared libraries there…
Now compare this with Abiword- the fastest GNOME application that I know of…which has 69 shared libraries….
gedit does start faster than abiword. But not by much…but less than 2 seconds on my machine…
Konsole (3.3) has 40 shared libraries-but even with prelinking turned on it is still -even after having been loaded several times -significantly slower starting up-but it wins when it comes to drawing text-it is 2 as fast gnome-terminal- but this is mostly due to how Konsole invokes the freetype font drawing library…..xterm only has 21 share libraries…
I am not saying here that GNOME is incredibly fast- but it is noticably faster than it ever was before. GNOME-2.10 and 2.8 are primarily bug fix releases-sure some new things have been introduced -but the majority of the changes are fixes to bugs that existed in the earlier releases…
Another strange thing I noticed:
When I first updated to 2.10 I was disappointed by the lack of thumbnails both in Nautilus and on the desktop- I only got thumbnails for videos and pictures-but not for pdfs and text files(as was standard in 2.8). Then I was playin around and went back and enabled composite in xorg.conf and voila I now have pdf thumbnails in nautilus and the desktop-and whats really cool is that compositing is actually being used-when I drag windows around the desktop I no longer see any redrawing of the desktop and its icons…..
I meant this: http://www.gnustep.org/resources/documentation/User/GNUstep/faq_1.h…
Hi,
I’d just like to comment that Gnome 2.10 have seen many speed improvements over the development cycle. Specially GTK+ which improved the use of pango to lower start up times and made an icon cache to perform less seeks on the hard disk. These are the most important ones but there are other minor speedups all over the place.
Now, since GTK+ have been imporved a lot, this will impact every signle program on the gnome desktop. But individual applications have been optimized too. For example, gnome-games, yelp, nautilus and evolution. The last one being the most noticeable one IMHO. Evolution 2.2 uses a lot less memory even with a huge number of mails and it starts up a lot faster too (note that Evo 2.0 was fast enough already).
So please, bear in mind that this optimizations happens gradually with every release making little steps forward in the right direction.
All that said, I think the most important feature in this new release is the huge number of bugs closed. So we all will be enjoying of a very stable Gnome Desktop.
Cheers,
-William
Just to backup what I said with hard numbers:
I compared gedit 2.8.1 (from FC3) with gedit 2.9.6 (from ubuntu latest live cd). I strace them and saved the output in a log file, then counted the open system call with “grep open file.log | wc -l” and I got this:
2.8.1 => 2709
2.9.6 => 847
Remember that 2.8 uses GTK+ 2.4 and 2.9 uses GTK+ 2.6.
Cheers.
Just a comment on gnome-terminal: It *can* be fast. The problem is that performance-improving patches for vte (the library that does all the real work in gnome-terminal) are still languishing in Gnome’s bugzilla because nobody has yet stepped forward to take over maintaining vte. Maybe some frustrated OSNews reader could do it…
Without a maintainer, those patches won’t be applied to the main code tree. Some distros (Gentoo, for one) apply those patches on their own, so gnome-terminal is quite usable. Displaying lots of scolling text (like the output of “emerge update system”) in gnome-terminal takes less than 2% of my CPU time, as opposed to 50% like someone mentioned earlier. And that’s with an alpha-blended background and antialiased text.
Because Gedit isn’t an ordinary text editor, it’s a programmer’s editor. That’s what we’ve been babbling about all day. How many times do we have to tell you how silly it is to compare notepad to Gedit?
Then why Gnome doesn’t come with a simple editor? Joe Sixpacks doesn’t really care of programming and developers tend to use more powerful editors.
To the person who said KDE is less resource intensive than GNOME, that’s a BIG LIE! Not only do C++ apps take forever to compile, they take forever to launch and they consume at least twice as much memory as do C apps.
It is no wonder that the slowest popular apps on Linux are all C++ based.
Don’t blame C++. Blame g++ and its legendary unefficiency.
Then why Gnome doesn’t come with a simple editor? Joe Sixpacks doesn’t really care of programming and developers tend to use more powerful editors.
Because Gedit is simple enough for Joe or Jane. What’s your point? Unlike some other environments, I’d rather GNOME ships one and only one editor.
Don’t blame C++. Blame g++ and its legendary unefficiency.
Can you back up that statement, or am I just to believe legend?
Because Gedit is simple enough for Joe or Jane. What’s your point? Unlike some other environments, I’d rather GNOME ships one and only one editor.
GNOME doesn’t really need a programmer’s editor that is too powerful for Joe/Jane and not enough for a real developer. I believe leafpad would be a much better option.
Can you back up that statement, or am I just to believe legend?
I use tons of C++ applications that were not compiled by G++ and I never got a memory consumption/speed issue with them. Folding@Home for Linux also got a 20% performance boost when it switched from GCC to ICC.
I use GNOME and KDE and both are pretty much equally fast/slow. I would not be surprised that pure C code is faster than C++ code but I would be that C code with an hacked object/class system would be. But hey, feel free to prove me wrong. After all, you’re the one claiming that the slowest Linux apps are using C++…