[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Query on kdelibs/kdecore/io/kgrantpty.c
From:       "Gabriel Anderson" <zettablade () gmail ! com>
Date:       2007-07-30 13:06:06
Message-ID: 26bbda730707300606x51c1d81fo20f0c8bd041b3e7d () mail ! gmail ! com
[Download RAW message or body]

On 7/30/07, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> On Monday 30 July 2007 07:25:56 am Gabriel Anderson wrote:
> > > Because the way your program does it and the way the OS does are not
> > > directly comparable -- the way the OS does it is much cheaper.  It's like
> > > buying in bulk 'cept you get the bulk price even if you only buy one
> > > unit.
> >
> > So the difference between the OS freeing allocated memory and manually
> > freeing is noticeable?
>
> Yeah, memory that is free()d is returned to the heap, various structures that
> track the heap are manipulated, a page might be unmapped (and tlb updated) or
> at least the memory is available for another malloc().
>
> When the OS cleans up, it just unmaps all pages associated with the process,
> and then updates the tlb "in bulk".  It also has to do this even if the heap
> is empty.
>
> If you allocate 1024 4-byte pieces of memory, then exit.  It will be much
> faster than allocating 1024 4-byte pieces of memory, releasing them all, then
> exiting.  The exit itself might be marginally faster, but you'll lose all
> those gains it the first dozen or so free()s.
>

It seems to me like it would be much better to leave a comment at the
end of the program stating which allocated variables are going to get
freed when the heap is deallocated.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]