From: "Carlos Pereira" [jose.carlos.pere...@ist.utl.pt], Date: 10/02/2011 09:10:
>> something), but aside from that it's a pure waste of CPU cycles. > I am sorry, I totally disagree. > I can only see two cases. Either fixing these hundreds and hundreds of > mem leaks is easy or difficult. > In the first case, is just a question of plain laziness and bad > programming practises. The second case is much worse, it means the code > is badly designed. A leak is a resource that outlives its lifetime, and becomes "lost". Where are these leaks you're so worried about? Some of them can be recovered by shutting down services that were started due to being required by what you WERE doing. Those services will be shut down when there's no chance of needing them again. If that happens to be at application shutdown, then why not allow the OS to reclaim them in bulk, if doing so will properly and correctly recover those resources. As has already been pointed out at least once, memory allocated during initialisation (possibly of components required but otherwise independent from the one you were actually using) that isn't a progressively worsening problem during the applications lifetime (the definition of a "leak"), and will be properly released by the OS at application shutdown, the cost of manually releasing those resources can amount to a significant and utterly unnecessary waste of effort. Especially, and this is something I know about well as someone using older and limited hardware, if some of those resources or the referring structures thereof, are presently stored within swapped out memory. I really don't want to have to sit around for an extra 10-20 seconds while a closing application crawls along pulling data from swap space for no particularly good reason, when the OS could have simply marked those pages as available and been done with it. Fredderic _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list