Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI Novell

Bounties for Gnome Optimization 469

Posted by CmdrTaco from the that's-a-really-good-idea dept.
Eugenia writes "Novell and OSNews are sponsoring the memory reduction project led by Novell's Ben Mauer by providing bounties to developers to help to clean up bloat in GNOME and related programs."
This discussion has been archived. No new comments can be posted.

Bounties for Gnome Optimization More

Bounties for Gnome Optimization

Comments Filter:

  • Gnome Optimization (Score:5, Funny)

    by Decaffeinated Jedi ( 648571 ) on Sunday March 06, 2005 @11:20AM (#11858416) Homepage Journal
    I tried to optimize my gnome once with a suit of +2 leather armor and a new red hat, but he still ended up getting slain by a bunch of kobolds.
  • Money is sometimes a very good incentive, but sometimes things you work for money don't seem as much fun. It's hard to explian but it's true. When you get paid to build a system, it's not as much fun as when you build your own system. Myabe its the whole intrinsic vs. extrinsic motivation thing. My two cents.
    • It's also a different feeling when working for a contest/bounty and a day job... This is a Good Thing (tm).
    • The way I see it, the money will just make sure that it gets on top of Slashdot :) and thus a lot of geeks, some with free time, will see it and go, "hey, that sounds interesting - and there's even something in it for me if I do it right!"

      People who wouldn't have otherwise thought of trying to clean up Gnome will give it a shot. Go, Novell!

    • Re:This can work both ways (Score:5, Interesting)

      by Doc Ruby ( 173196 ) on Sunday March 06, 2005 @12:01PM (#11858611) Homepage Journal
      There's no reason why a team of people couldn't work together daily, in a traditional "day job", to produce software to submit to these bounties. In fact, given that the risk of the code not making into acceptance by deadline is now borne by the coders, a team that's working on several bounties at once (perhaps in different projects) a better way to spread the risk. This model lets a team work on what they want, when they want, for whom they want, with whom they want. Without all the baggage that's bundled with a day job at the buyer of the code, including the mixed bag of projects assigned to team members.

      • Re:This can work both ways (Score:5, Interesting)

        by Rahga ( 13479 ) on Sunday March 06, 2005 @12:47PM (#11858870) Journal
        Here's a reason: Most people with the experience needed to do this work easily make well over the ammount these bounties offer (~$200 for something that is very non-trivial) in less than a day or two at their day job. The bounties are simply added incentive to fix messy problems, very rarely will you see somebody take them on unless they already wanted to scratch that itch.
        • I agree [slashdot.org]. The bounties are too low for the sole motivation of a good programmer. Opening the market like this could produce an efficiency in code reuse that we'd all welcome - programmers "doing it already" (for some other payment) would be incented to send it to the distributor which can send it to more consumers, justifying their investments in the bounties. Or it could send the programming work to either worse programmers, resulting in worse code, or to poorer programmers, deflating the cost of coding - a

  • Its about time (Score:5, Insightful)

    by laffer1 ( 701823 ) <luke@@@foolishgames...com> on Sunday March 06, 2005 @11:23AM (#11858433) Homepage Journal
    This is great news. I switched from KDE about a year ago because of the newer gnome interface. (2.4+?) I run gnome on FreeBSD 5-stable and found that my biggest complaint is the memory usage. I have a dual xeon 2.0 gig with 1 gig of ram and gnome + xorg eat up at least 200-300mb of the ram. Maybe while they are at it they can fix some other problems with gnome like the fact the default stack size needs to be increased in many non linux systems when porting it!!!!!

    • Re:Its about time (Score:5, Informative)

      by Espectr0 ( 577637 ) on Sunday March 06, 2005 @11:52AM (#11858572) Journal
      Kde has improved dramatically in speed , memory reduction and html rendering in konqueror in the last year.

      You may want to give it back a try.

      We use kde in our offices, which are pentium 2, 400mhz and as little as 128mb (!) of ram.

      On my development box, i have a dual 400mhz P2 with 320mb in ram, and i can run eclipse with tomcat

      • Re:Its about time (Score:3, Interesting)

        by m50d ( 797211 )
        I run kde successfully in 62mb of ram

      • Re:Its about time (Score:3, Insightful)

        by drsquare ( 530038 )
        I'm not so sure about that, I have 512MB of RAM, Athlon 2000, and it takes 10 seconds at least for KDE to start up. This just for a very small part of the OS which doesn't really do an awful lot other than put borders and titlebars on Windows.

        As for Konqueror, well I think Firefox has taken the open-source browser crown. Saying that, I use Konqueror for browsing images on the local filesystem. As a general file-manager it's not really up to it, and it's not really up to it as an Internet browser. I think t

      • Re:Its about time (Score:3, Interesting)

        by Eil ( 82413 )

        I can vouch for this, the KDE desktop and all of its apps are nice and snappy on my aging Athlon 750. To put this in perspective, Firefox--a widely acclaimed "small footprint" browser--feels like bloatware in comparison. I use it over Konqueror only because I can use the Adblock and Googlebar plugins with it.

    • Re:Its about time (Score:3, Informative)

      by Earered ( 856958 )
      I was able to use gnome 2.8 on a Celeron 433 with 64Mo of RAM. Though you either need to tweak your configurationhttp://www.gnome.org/learn/admin-guid e/2.6/ch09.html/ [gnome.org]
      or to use a dedicated distribution like Beatrix http://www.watsky.net// [watsky.net]
      which include gnome and use dirty trick with the kernel to improve performance.
  • This is a realy good idea, something like this should be done not only to GNOME but also to other window managers such as KDE. Even non linux based systems could need some work when it comes to memory leakage and optimization. This does'nt only help people with little RAM but helps everyone.. Hope everyone are willing to help.

    • Re:This is a realy good idea (Score:5, Informative)

      by Dan Ost ( 415913 ) on Sunday March 06, 2005 @11:35AM (#11858495)
      Please don't call KDE a window manager.
      Both KDE and Gnome use window managers, but neither of them are window managers
      (the fact that you can change which window manager is used by KDE and Gnome
      is a good indication that they, themselves, are not window managers).

      xwinman.org gives an excellent introduction to both window managers and
      desktop environments. Give it a look.
      • xwinman.org gives an excellent introduction to both window managers and desktop environments. Give it a look.

        FYI, anything that is talking about the recent release of KDE 2.0 is just a tad dated. The concept is neat, but somehow I doubt the site is at all maintained.

    • KDE has been doing this since day one (Score:5, Insightful)

      by AntiOrganic ( 650691 ) on Sunday March 06, 2005 @12:20PM (#11858711) Homepage
      While they've still got a long way to go, each successive release of KDE is substantially improved in terms of required CPU power and memory usage. KDE 3 ran a great deal faster than KDE 2 despite all sorts of added functionality, and KDE 3.4 RC1 is the fastest yet by a pretty big margin. The upcoming Qt 4 has a whole slew of performance improvements which should reduce requirements further.

  • Next Bounties (Score:5, Funny)

    by buckhead_buddy ( 186384 ) on Sunday March 06, 2005 @11:24AM (#11858444)
    And the next set of bounties will be offered for cleaning up bugs introduced by rapidly encouraging people motivated only by money to make changes to Gnome without fully considering the ramifications of these memory reductions. :-)

    • Re:Next Bounties (Score:3, Insightful)

      by Rahga ( 13479 )
      Well, those patches would no only have to pass scruitiny by those offering the bounties, but more importantly, the package maintainers as well. I'm not concerned.

  • Feasable Career? (Score:5, Funny)

    by dingo ( 91227 ) <{gedwards} {at} {westnet.com.au}> on Sunday March 06, 2005 @11:25AM (#11858446) Journal
    I wonder if there will ever be enough bounty's on offer to make a career out of it.

    I can just see all the coder bounty hunters with their boba fett helmets on.

    • Re:Feasable Career? (Score:4, Insightful)

      by skraps ( 650379 ) on Sunday March 06, 2005 @11:55AM (#11858585)
      I wonder if there will ever be enough bounty's on offer to make a career out of it.

      Not at $100 or $200 a pop, notta chance. I think these are mostly to encourage the existing gnome hackers to attack some less-than-glamorous problems they would rather not do normally. I doubt we'll ever see a wild wild west bounty hunter who just roams around between vastly different projects. If the improvements were that easy to make, someone already on the team would just make them instead of giving up money. If they aren't that easy, like these, then you wouldn't be able to solve enough of them to pay your rent.

  • gnome-terminal (Score:5, Informative)

    by karmaflux ( 148909 ) on Sunday March 06, 2005 @11:25AM (#11858447)
    Gnome-terminal is going to make someone ridiculously wealthy. Seriously, there's so much room for optimization that a good coder will be able to retire off that one program.

    • Re:gnome-terminal (Score:2, Interesting)

      by schleyfox ( 826198 )
      aterm is GPL, right? excellent

      1. Rip out gnome-terminal and piss on it
      2, slide xterm or aterm into its place
      3. Profit?

    • Re:gnome-terminal (Score:2, Interesting)

      by b374 ( 799492 )
      From TFA:
      Aivars Kalvans has submitted two great patches on bugzilla. One of them cuts 250 kb of malloc'ing for each tab you open in gnome-terminal. This will save me at least 5 MB on my desktop. It is still pretty messy (it was 500 kb per tab before his patch), and much worse than konsole (which takes 50 kb per tab).
    • Gnome-terminal is going to make someone ridiculously wealthy. Seriously, there's so much room for optimization that a good coder will be able to retire off that one program.

      I call bullshit. I've benchmarked a few terminals, since sometimes my programs spew out tons of crap. Gnome terminal won in terms of speed (as long as you don't use antialiased fonts). rxvt was not far behind. XTerm was pitiful, especially if you have a large scollback buffer. KTerm was far behing xterm, unless XTerm has a large buffer
      • > KTerm was far behing xterm, unless XTerm has a large buffer, since it seems to slow down linearly with buffer size.

        If by "KTerm" you mean Konsole, I will say that it was only recently that I could switch to Konsole - probably KDE 3.2.x because it used to be too slow. It's now indistinguishable compared to xterm in my opinion. Mapping multiple sessions to ALT-F1-F6 like the linux console inside of konsole makes it more functional than xterm... I've switched for good.

        (Although for remote sessions I'
  • ...seem to be doing great stuff for the Gnome community and Linux in general more and more.

    I know they have a vested interest but this is great stuff.

  • bloat in gnome... (Score:3, Funny)

    by mickyflynn ( 842205 ) on Sunday March 06, 2005 @11:26AM (#11858456)
    'cause a bloated gnome is just a hobbit... which is actually cooler.

  • Fine, give them money, but... (Score:4, Insightful)

    by TapioNuut ( 615924 ) on Sunday March 06, 2005 @11:29AM (#11858467) Homepage
    Offering money is a great way of getting people interested in many things, but do the people who are capable of creating valuable bug reports and/or patches really need these bounties?

    I wonder how many crappy bug reports and patches are to be submitted because of the "easy" money being given. I do believe that the bounties will go to the right people and for the right reasons, but more the crap, the more it takes work to find the gems.

    Nevertheless, it's about time to unbloat Gnome.
    • Except you don't get the money just for coming up with something. It has to be selected, which means other people have to approve it. Which means it has to be good.

      "I wonder how many crappy bug reports and patches are to be submitted because of the "easy" money being given."

      0. Just because you submit a bug report doesn't mean it becomes a bounty.

  • Novell's attitude towards Linux desktop (Score:5, Insightful)

    by unixmaster ( 573907 ) on Sunday March 06, 2005 @11:35AM (#11858493) Journal
    As you can see from Novell's actions they are totally biased towards Gnome but still they make more money out of Suse distribution which uses KDE extensively.

    Feel the irony?

    They should instead be desktop neutral and support KDE developers too...
    • It's not irony. It seems quite obvious that they are preparing to make Gnome the default desktop in Suse. I imagine while they're improving Gnome they're also porting all their configuration tools to work with it.
    • They bought Ximian which employs the key Gnome project managers.

  • motivation or reward? (Score:3, Insightful)

    by jd142 ( 129673 ) on Sunday March 06, 2005 @11:38AM (#11858508) Homepage
    Is this motivation for people to find the bugs, i.e., there's some programmer out there thinking, "Hmm, if I do this and this, then Gnome will run three times as fast. Oh well, I'm a KDE supporter so I don't care." Or is this a way to reward all of those people who do care about Gnome and are working on it by giving them a specific area to concentrate on and then rewarding them for their hard work, in other words some programmer thinking, "Hmm, I've got some free time and I can either work on fixing eyecandy or fixing memory leaks. Guess I'll fix the memory leaks first and get a reward."

    Everyone has been assuming that this is pure motivation, appealing to the greedy nature of people who aren't already contributing. I don't think that's the case. Generally speaking, those people who are good programmers and know the code well enough to actually identify and fix problem areas are probably already doing so. This "bounty" seems to be more a way of rewarding them and helping to give them a list of priorities.

  • not the eugenia from osnews now is it?

  • This can only be good (Score:3, Insightful)

    by schleyfox ( 826198 ) on Sunday March 06, 2005 @11:45AM (#11858544)
    I like this, from my observations it alwasy appears that OSS is a bit heavy on the memory while closed source tends to be heavier on harddrive and processor dependent (not to say it is bloat free, far from it). That said, I run Gnome 2.8 on my old Pentium 2 laptop with 128mb of RAM. It actually works decently well, other than the screen refreshes which can use up all my processor and still take a few days :) . It is quite usable though and future versions of gnome will hopefully perform even better. Thank You Novell

  • Time and space complexity concerns (Score:5, Interesting)

    by rbrito ( 37104 ) <rbrito AT ime DOT usp DOT br> on Sunday March 06, 2005 @11:47AM (#11858551) Homepage Journal
    Now, it seems that (finally) developers are looking at resources that our programs use.

    Unfortunately, for many in developing countries (like me, here in Brazil) having a computer filled with RAM and with the fastest processor available on the market isn't an option.

    For instance, my desktop has a Duron 600MHz with 256MB of RAM. That's the fastest computer to which I have access here and it is some years old, but still working fine.

    I can't say how happy I am with this bounty for optimization of memory.

    In Computer Science we always have this concern with both time and space complexity and it seems that if Free Software developers start caring about good data structures and good algorithms (and avoid layers and layers and layers of abstraction over and over), we can actually use our computers more efficiently.

    Again, this is especially important for those who have to use computers of two or three generations ago.

    A welcome movement indeed.

    P.S.: If you have never felt the need for less memory comsumption, then you won't probably understand how important this project is and probably this post makes little sense to you.

  • Perfect Labor Capital Market (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Sunday March 06, 2005 @11:49AM (#11858562) Homepage Journal
    We might finally have the open source capitalism model that kills these "commie" snipes dead, and leaves proprietary competitors dead in the water. Offer to employ programmers by buying their labor in a contest! Leverage the open source on the Net to get as many job applicants as possible, who submit the finished work, then give the "job" to only a single winner whose superior work is used. The losers need only inspect the open source of the next version for any of their content to keep the process honest.

    This creates parity for labor in the capital markets. Programmers can sell their labor as a packaged product, just as vendors can resell the programs to consumers. Programmers can market their code with better documentation, APIs and popular features. While integrators like Novell can get access to the labor market, without risking that the labor they're buying is better at job interviews than at delivering on deadline.

    There is an issue of the "waste" of the losers' code submissions. But since these projects are open source, the losers can fork the project and compete with it. If the losers are really better, they can compete better with the original project - which itself might be forked by the original contest sponsor. Brand equity will determine winners in the long run, but the open source lets brand equity be earned by persistent quality, as determined by the consumer market, rather than the funder of the code.

    Ladies and gentlemen, start your engines!
    • 1. Create a "contest" for some code.
      2. Take none of them, or take a fake submission you created yourself
      3. Let the fool create a forked project
      4. Get the code for free (It's open source right?) and integrate it in the project.
      5. Profit!
      • How would you integrate it into the project, without publishing it, and getting caught? If you published your own code, why would you bother recruiting others' code (unless yours were actually better)?
        • There is no need to hide the fact that you took the code. It is perfectly legal and ethical to take GPLed code and integrate it into another GPLed project.

          Thus, what I'm saying is that to get a guy to create GPLed code for you for free, you only have to start a "contest", don't take the guy's submission, wait until he forks your project with the code he created for the "contest", and integrate that code in your own project. Perfectly legal and ethical, since your project is also GPL, and you didn't pay a p

  • Ditch the dependencies and deprecated code (Score:4, Interesting)

    by Florian ( 2471 ) <cantsin@zedat.fu-berlin.de> on Sunday March 06, 2005 @11:50AM (#11858565) Homepage
    The bounty is a first good step, but the Gnome project will have to go much deeper to get rid of its bloat.
    • Remove all deprecated libraries from the codebase of the Gnome core.

      In its history, Gnome has changed its libraries and subsystems several times, from imlib to gdk-pixbuf, from gnome-canvas to pango, from Corba to Bonobo to possibly Mono, from esd to gstreamer, and so on. Many Gnome apps still use older, deprecated libraries. Get rid of those libraries and port all apps to the standard core API.

    • Remove or replace subsystems which never really were useful

      I'm thinking of Bonobo and gnome-vfs here which are not consistently used in Gnome and whose quality and use value is questionable. If their functionality is still needed, it could be replaced by KDE's superior kioslaves and kparts (just as KDE is ditching its arts sound demon in favor of gstreamer)

    • Make all demons optional

      Neither Gnome, nor KDE applications should be depending on any desktop-specific userspace demons. Make it possible to deactivate gconf, for example, and have applications read and write configuration files the classical Unix way, by one central switch. Make the sound demon optional, so that audio output could just be written (in old-fashioned, non-overlapping way) to /dev/dsp. Etc.etc. The demons might have some use for some people, for for many, they are just bloat and unnecessary complexity.

    Yeah, I know that all would be a Herculean effort. Probably, it makes more sense to start with a lean and clean codebase like XFCE and just bring its usability to Gnome level, instead of cleaning up a bloated mess...
    • Yes, what you suggest would be a substantial effort, but it all makes sense.

      I particularly like:

      Make all demons optional

      Neither Gnome, nor KDE applications should be depending on any desktop-specific userspace demons. Make it possible to deactivate gconf, for example, and have applications read and write configuration files the classical Unix way, by one central switch. Make the sound demon optional, so that audio output could just be written (in old-fashioned, non-overlapping way) to /dev/dsp. Etc.etc.

    • Re:Ditch the dependencies and deprecated code (Score:4, Informative)

      by jcupitt65 ( 68879 ) on Sunday March 06, 2005 @12:35PM (#11858796)
      That's a good idea. There's also a lot of deprecated API (eg. GtkCTree) which can be removed from the system with just a few -Dsomething during configure. You can turn off the GObject run-time type checks with another -Dthing, which helps speed another 10% or so in my experience.

      Bonobo is slowly being removed since GtkUIManager came on the scene. I think gnome-vfs will be around for a while, especially since the new file chooser can plug in to it (I think).

    • > Remove all deprecated libraries from the codebase of the Gnome core.

      I believe that deprecated libraries tend to be replaced by stubs that backport the new functionality to the old API. Eg, the gnome_sound_play function currently sends a sound file to Esound; when (if) GStreamer becomes part of the platform, the function in libgnome will be replaced with code to do the same thing in GStreamer.

      The old APIs can not be removed until the developers decide to make a new release backwards-incompatible--this will be Gnome 3.0 (http://live.gnome.org/ThreePointZero [gnome.org]).

      > Remove or replace subsystems which never really were useful

      Most people I see using Gnome use GnomeVFS all the time. Being able to access files shared on the network without having to be root to mount them is really nice. Even nicer is the sftp virtual filesystem, used for accessing files over SSH's SFTP. If GnomeVFS is to be replaced by something else, it will be by freedesktop.org's D-VFS.

      As for Bonobo: I believe panel applets use it all the time, and I don't think KParts can be a sensible replacement for it: Bonobo isn't just for GUI components. Since it is a Corba implementation, one can use out-of-process components with it, as well as components running accross the network. It's more like DCOM, whereas Kparts are analogous to ActiveX.

      Furthermore, I don't see the Gnome developers starting to use C++ any time soon. Besides the matter of taste and familiarity, C++ has problems with ABI stability. It took an age for Debian to recompile every C++ program when GCC 3.2 came out; I believe one of the reasons GCC 3.4 won't be in Sarge is because it breaks ABI compatibility again.

      > Make all demons optional

      Sounds like you want to duplicate the code from the daemons and copy it into each application. This would only increase memory usage and the number of bugs, while decreasing functinality. The reason GConf is really, really good is because of the signals/notification system. I'm not sure one's desktop would run much faster if every program one used polled its config file for updates every second.

      As for Esound, it will go away in the future if GStreamer becomes a part of the Gnome platform. This will be really nice when it happens, because the job of picking which sound server to use (esd/polyp/arts/jack/none), configuring it, etc will be left up to the distributor. But GStreamer has a fair bit of improvement to do before this can happen; and since removing Esound all together is backwards incompatible, it will have to wait for 3.0.
    • Making daemons optional is really not a reasonable request. Removing deprecated libraries would really solve the problem that there are too many daemons. However, it makes complete sense that all configuration should be done through a daemon so that someday you can store all your configuration in a sql database, or as extended file attributes on a reiserfs system, or what have you. It makes more sense to use the daemons to provide the functionality to all apps in the same way, and to expect all of those app

  • While they are at it ... (Score:5, Interesting)

    by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Sunday March 06, 2005 @11:53AM (#11858576) Homepage
    fix some of the startup slowness. Have you ever done strace on a gnome app ? Did you ever see it open and read the same file again & again ? It might cost a little RAM to cache the results but should be worth it - most of these files are quite small. How about reading into a per user shared memory segment - just read once and share between all processes.

    The best way of ensuring that it stays fixed is to give all the gnome developers PIIIs with 128 Mb RAM.

    • Yeah, give them pills instead of bounty. ;)
  • NO disintegrations.

  • Pay Peanuts, Get Monkeys - Catch Fleas (Score:5, Insightful)

    by Doc Ruby ( 173196 ) on Sunday March 06, 2005 @12:23PM (#11858725) Homepage Journal
    The bounties Novell is offering [gnome.org] are too low. They're offering $1-200 for tasks that will take an adequately skilled programmer, already familiar with GNOME, something like 2-4h to complete, including the docs that will let GNOME integrate the code (which will help win the bounty). The programmer doesn't need to spend time testing the code, though that will increase their chances of winning. So they're offering $50:h.

    That isn't enough to support a community of coders, even if the range of bounties were scaled up to supply a significant headcount with enough work to keep busy (say, 500-1000 bounties a year). The labor might be fueled by people who are coding GNOME anyway, to prioritize completion/submission of some tasks. But the better, even more productive coders won't be available at those rates. It remains to be seen whether a multitude of mediocre submissions can compensate for too-cheap bounties that can't attract quality coders. Or perhaps this model will merely send all coding offshore, to programmers who can work so cheap that a single $100 bounty won can fund a month of unsuccessful submissions to other bounties they lose.

    • Are you kidding me? (Score:3, Interesting)

      by Inoshiro ( 71693 )
      When you're like me, working through Univursity to pay for a computer science degree that's being paid concurrently, these are great. Rather than going to a soul killing job that has no relevance to my course of studies, but happens to pay me money, I can just do a mod to Gnome (which is relevant to my studies), and get paid 10 times my soul-sucking hourly rate.

      This isn't for people who have jobs which pay them so much money they can have sexy-parties with hookers and blow every Tuesday, this is for peopl
    • It'll take me longer just to install GNOME and get it working, on my P3/600 with 128MB RAM than it will for some of these things to get fixed.

      And to install the entire development trees and actually do a compile? Ludicrous. heh.

  • Good luck! (Score:5, Interesting)

    by daVinci1980 ( 73174 ) on Sunday March 06, 2005 @12:30PM (#11858761) Homepage
    Seriously... I've spent a very significant amount of time optimizing four shipped titles now--mostly games, one commercial shrinkwrap application--for both speed and size tradeoffs.

    The big annoying thing with optimization is that assuming you are working with talented people (I believe the people who work on GNOME are talented), there is generally little low-hanging fruit. An example of low hanging fruit is places where you are using--for example--a vector, but you should be using a map or a hash table. Another example is places where complex code can be skipped over by checking some preconditions and bailing early.

    Although premature optimization is the root of all evil, most of us recognize these sorts of places early, and do the relevant optimization work in the first place. What you're left with in terms of optimizations is places where your initial architecture is *just wrong.* This kind of performance / memory deficiency really sucks, because most of the time the code is too complex and there are too many other dependent pieces of code to do the necessary rewrite.

    The other thing that makes optimization work hard is (lack of) tools. There are basically two types of problems you can optimize: speed and size. Sometimes you get lucky, and fixing size problems *also* increase speed (generally because your smaller code now fits in the instruction cache, or because your data memory fits in the L1 or L2), but that is usually the exception. With size problems, the best bet is usually to make all objects pooled individually. This allows you to dump out information during the program run as to how many objects you've allocated of a particular class, as well as how much memory they're taking up.

    With speed concerns, it's a little more difficult. There are basically two types of speed problems. Problems that occur constantly, and problems that occur as a result of user interaction or are themselves cyclical. Effectively it's a matter of identifying spikes versus identifying plateaus. Plateuas are the easier of the two, because they are identifiable via tools like Intel's VTune (which has been--I believe--ported to Linux by Intel). But spikes are harder, in that identifying them requires code instrumentation, and although there are some suites that will do it automatically, they often over instrument places which lead to artificial spiking.

    Anyhoo, sorry for rambling... optimization is something very near and dear to my heart.
    • Before you even touch any vector-to-map conversions you should make sure your disk IO is optimal. If you are reading/writing/opening any file more than once, you will see no measurable gain from adding binary search to some measly thousand element vector. If you are using the network without a pretty darn good reason, or not caching the results, you can forget about doing any other optimizations. If you need to start twenty daemons to run a word processor, you have some serious architecture design issues.

      I

  • Additive bounties (Score:5, Interesting)

    by theantix ( 466036 ) on Sunday March 06, 2005 @01:42PM (#11859210) Journal
    What I would like to see is the ability for me as a user to add to the existing bounties and start new ones of my own. I would like to be able to propose a bounty and send money to a reputable bounty clearinghouse like at Novell or Ubuntu, and then they could offer the bounty as if it was their own since they have my cash until the bounty expires or is completed. And then while the bounty is still up for grabs I would like to be able to send the clearinghouse money to add to the existing bounties in order to make them more lucrative to potential hackers.

    I could setup this site right now fairly easily, but people wouldn't trust my joe random site as well as they would trust a bigger and more established organization like Novell or Ubuntu/Canonical. But I can't be the only one looking to put my money where my mouth is, so why does this functionality not exist?

    • I like the idea (Score:4, Insightful)

      by hsoft ( 742011 ) on Sunday March 06, 2005 @01:52PM (#11859267) Homepage
      Sourceforge should extend it's donation system and create a bounty system. When you donate money to a project's bounty system, you get a vote for each dollar you give. People submit for the bounty, and then, you can vote for who will get the coding contract.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close