Gnome optimization

[bvc]

removing white space and return characters really doesn't make that big of a difference in the grand scheme. XML files usually aren't stored in memory, just read when a program starts for the necessary information and possibly a few times during program usage - but if a program is loading XML files into memory on a regular basis it's inefficient. XML should be read to get variables, and those variables should be what are stored in memory (with the program) - at which time all the white space and return characters aren't present anyways (if the programmer is worth his salt).

 

That's right, but it takes some time to read the whole file, rendrer it, then find a needed key/option. The larger a file - the more time you need to render it and then search for a proper option. Deleting white spaces and return chars makes a file much smaller (though less readable for human).

It is pity you can not read the original post, they give some clever explanations there, and i think i support them. Some said that gnome's xml parser is kind of a slow.

 

but if a program is loading XML files into memory on a regular basis it's inefficient. XML should be read to get variables, and those variables should be what are stored in memory (with the program) - at which time all the white space and return characters aren't present anyways (if the programmer is worth his salt).

 

If the program reads xml file and then stores it in variables, than indeed xml file is read only few times while the program is running. If it is so, then how does gnome enable instant apply of gconf? In kde for example you don't have this feature.

gconfd-2

I don't know if dbus has anything to do with it or not

[tyme]

If the program reads xml file and then stores it in variables, than indeed xml file is read only few times while the program is running. If it is so, then how does gnome enable instant apply of gconf? In kde for example you don't have this feature.

That's quite simple. The program knows that you've modified the field. It automatically writes the change to both the variable that's loaded (and then reloads it to apply the change) and to the XML file. I haven't personally seen the code for this, but that's how I would write it (and I assume the GNOME programmers are smarter than I am).

That's right, but it takes some time to read the whole file, rendrer it, then find a needed key/option. The larger a file - the more time you need to render it and then search for a proper option. Deleting white spaces and return chars makes a file much smaller (though less readable for human).

have you ever written a program to read in data from a file? white space is largely ignored, and return characters are only read if used as markers for EOL. The programs reading in these files are searching for a specific tag and believe me, with any modern system, you're not going to notice much of a speed-up by removing white space and return characters even if the program is processing them.

 

I'm sure the people who created this have some sort of logical reason for it in their minds, but I wonder if they've ever written a program to parse an XML file.

[ilia_kr]

simpe enough :)

[ffi]

My guess as to why KDE is faster than GNOME (although I am a KDE user but never noticed a speed difference a great speed difference) is that KDE preloads a lot more into memory but many people don´t like this as it seems like memory hogging....but hey you don´t have all that ram to leave it unused, do you?

[ilia_kr]

My guess as to why KDE is faster than GNOME (although I am a KDE user but never noticed a speed difference a great speed difference) is that KDE preloads a lot more into memory but many people don´t like this as it seems like memory hogging....but hey you don´t have all that ram to leave it unused, do you?

 

 

I don't have that much ram only 256mb. And you're right about KDE, I read about that somewhere allready.

[tyme]

My guess as to why KDE is faster than GNOME (although I am a KDE user but never noticed a speed difference a great speed difference) is that KDE preloads a lot more into memory but many people don´t like this as it seems like memory hogging....but hey you don´t have all that ram to leave it unused, do you?

I believe I stated this before, but in all my recent experiences KDE has never seemed faster than GNOME. I know it preloads stuff into memory, and that's fine if that's what KDE devs like to do, but for me it just doesn't make any noticable difference. I'm sure it's measurable, but if I don't notice it when actively using the DE, then it doesn't really matter ;)

[ffi]

I believe I stated this before

 

I didnt read that before :unsure:

 

I dont notice a memory problem with KDE nor lag problem with Gnome, I just prefer KDE because its more useable than Gnome.

 

One thing I do notice however, scrolling sometimes gets bumby in Gnome/GTK especially is the lists are long, but not so in KDE.

Edited June 3, 2006 by ffi

[tyme]

I dont notice a memory problem with KDE nor lag problem with Gnome, I just prefer KDE because its more useable than Gnome.

well that's just a matter of opinion ;)

 

One thing I do notice however, scrolling sometimes gets bumby in Gnome/GTK especially is the lists are long, but not so in KDE.

never noticed that in GTK apps.

[ffi]

One thing I do notice however, scrolling sometimes gets bumby in Gnome/GTK especially is the lists are long, but not so in KDE.

never noticed that in GTK apps.

Maybe it´s an Ubuntu problem, I don´ use Gnome/Gtk apps much in Mandriva but after trying some didn´t notice anything here, still a problem on Ubuntu though....

[iphitus]

there's so many differences between KDE and GNOME, that to say that one is faster than the other is naive, and to say that one is slower because it uses XML is even more so.

 

all sorts of factors, such as their respective toolkits, the programs being compared, the configuration of the system, the way it is setup by the distribution have effects on each program's responsiveness.

 

compare say, krita and gimp, similar programs. To say that GNOME is faster because <insert filter> runs quicker in GIMP, is just completely baloney. That would have more to do with each programs implementation of <insert filter>, and it could well be that krita's <insert filter> does a better job.

 

My point is that, so much depends on the programs implementation, that to say the toolkit or desktop environment around it is to blame for it's responsiveness and interactivity, is just completely foolish. It has an effect, but is by no means the defining factor.

 

James

Edited June 4, 2006 by iphitus

[ilia_kr]

You see the speed difference when you use slow PC, like mine. I'm shure that if i had Linux on pentium 4 i couldn't notice a difference too.

 

One thing sure: konqueror opens folders much faster than nautilus, i've checked that on large ones and small ones. In KDE the menues pop up faster (i think that is because it takes some time to gnome to display apps icons).

The scrolling thing - didn't notice.

About usability - I find gnome simple and intuitive while KDE is quiet awkward and resembles windows to0 much (its boring :) ).

Edited June 9, 2006 by ilia_kr

[bvc]

Metacity uses xml and is a little slower than the 'boxes' which are usually text.

Interesting is the more code and the bigger the xml file, the slower the metacity theme is. My recent gFlat metacity theme buttons are all code, and the round version with round buttons is twice as slow as the square making it probably one of the slowest metacity themes (in code) ever.....slower than Clearlooks. There's twice the code for the buttons. But I wanted the buttons to scale with the font size so, that's the price I pay. Clearlooks doesn't do that, unfortunately, and I find it strange it is default w/o acessability.

http://www.gnome-look.org/content/show.php?content=40324

[tyme]

Interesting is the more code and the bigger the xml file, the slower the metacity theme is. My recent gFlat metacity theme buttons are all code, and the round version with round buttons is twice as slow as the square making it probably one of the slowest metacity themes (in code) ever.....slower than Clearlooks. There's twice the code for the buttons. But I wanted the buttons to scale with the font size so, that's the price I pay. Clearlooks doesn't do that, unfortunately, and I find it strange it is default w/o acessability.

http://www.gnome-look.org/content/show.php?content=40324

That makes sense as metacity has to read twice the options. If we just add an equal amount of whitespace to a theme with half the options, I doubt there would be any difference.

[iphitus]

with the more code, there's more rendering being needed to be done, and more instructions to be followed by the WM to draw the theme.

 

You could pad it with half a meg of whitespace though, and the theme would render in exactly the same time for every window, as the instructions are only loaded once, and are only parsed the once, when the theme is applied, or when the wm is started.

[bvc]

That makes sense as metacity has to read twice the options. If we just add an equal amount of whitespace to a theme with half the options, I doubt there would be any difference.

Yes, it has to read twice the options from a xml file, which itself is not efficient. I don't care about whitespace and have said nothing about them.

 

with the more code, there's more rendering being needed to be done, and more instructions to be followed by the WM to draw the theme.

 

You could pad it with half a meg of whitespace though, and the theme would render in exactly the same time for every window, as the instructions are only loaded once, and are only parsed the once, when the theme is applied, or when the wm is started.

If I understood a developer (I trust) correctly, metacity does not cache code for rendering, only pixmaps, which is why some (clearlooks for example) choose pixmaps for buttons. While the xml file may be cached, the rendering of the code is not. That's how I understood it anyway.

 

My point is with ilia_kr. Xml is slower than text, and that is a very well known fact. I guess metacity is probably not a good example because of what the xml is used for, and how, but that doesn't change the basics.

http://news.com.com/Putting+XML+in+the+fas..._3-5534249.html