| |||||||||||||
A GNOME 3.0 planA GNOME 3.0 planPosted Apr 3, 2009 6:42 UTC (Fri) by job (guest, #670)In reply to: A GNOME 3.0 plan by ovitters Parent article: A GNOME 3.0 plan
How about reducing memory usage to one tenth?
It should be realistic but a real challenge which would involve a lot of the underlying libraries. Just like the fast boot the Intel guys did.
As an example, my terminal is right now 30M rss and the yellow sticky notes is 40M. I understand this includes a number of non-trivial things, unicode libraries and whatnot, but it should be possible. This would enable a whole range of new uses.
(Log in to post comments)
A GNOME 3.0 plan Posted Apr 4, 2009 8:26 UTC (Sat) by oblio (guest, #33465) [Link]
http://www.joelonsoftware.com/items/2007/09/18.html
"As a programmer, thanks to plummeting memory prices, and CPU speeds doubling every year, you had a choice. You could spend six months rewriting your inner loops in Assembler, or take six months off to play drums in a rock and roll band, and in either case, your program would run faster. Assembler programmers dont have groupies."
Make stuff that works (aka stable), and make stuff that does things (aka has lots of functionality). Memory usage decrease - important, though hardly crucial for a major release, IMO.
A GNOME 3.0 plan Posted Apr 4, 2009 11:13 UTC (Sat) by nix (subscriber, #2304) [Link]
Note the past tense. It is still sort of true for memory consumption, but
even there reducing memory consumption (or, rather, short-to-medium-term working set) can increase speed, 'cos caches aren't anywhere near as large as RAM.
It is no longer true for CPU consumption. For non-parallelizable code
A GNOME 3.0 plan Posted Apr 4, 2009 13:29 UTC (Sat) by oblio (guest, #33465) [Link]
Even if it's parallelizable, you have all sorts of single core embedded CPUs, in which case it isn't true either. So I get your point.
But something like making a whole major release whose primary goal is to reduce the memory consumption of Gnome to 10% is prone to leaving Gnome in the dust bin of desktop history - you only have so much resources, and when you try this kind of optimization it becomes all you do, you can't really add features.
A GNOME 3.0 plan Posted Apr 5, 2009 19:50 UTC (Sun) by job (guest, #670) [Link]
First, I'm not sure someone who worked at Microsoft for three years writing about software methodology is an authority on this (as they never really succeeded in the embedded space compared to the amount of work and money spent). Second, even if Moore holds here as you describe that still gives you roughly five years for an order of magnitude increase. Don't you think a five year head start on your competitors is valuable?
A GNOME 3.0 plan Posted Apr 7, 2009 8:24 UTC (Tue) by oblio (guest, #33465) [Link]
"First, I'm not sure someone who worked at Microsoft for three years writing about software methodology is an authority on this (as they never really succeeded in the embedded space compared to the amount of work and money spent)."
What does Microsoft success in the embedded market (or lack thereof) have to do with the moral authority of someone writing about this topic? Logical fallacy in there :)
"Second, even if Moore holds here as you describe that still gives you roughly five years for an order of magnitude increase. Don't you think a five year head start on your competitors is valuable?"
It is valuable. But you only have so many resources. Do you really believe that you can go on an optimization spree, reducing Gnome to 10% of its current memory consumption, and still add features? Work on Vala, Zeitgeist, Gnome shell, stability improvements, Evolution Exchange backend, API changes, refactoring, deprecation of libraries, and still make everything 10x smaller? I highly doubt it that you can do it and ship before those 5 years are over. Therefore you win no time :)
A GNOME 3.0 plan Posted Apr 7, 2009 9:00 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Sounds like a nice Summer of Code task :)
|
|||||||||||||