Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is realloc good form ?

Reply
Thread Tools

Is realloc good form ?

 
 
Guillaume Dargaud
Guest
Posts: n/a
 
      10-18-2007
Hello all,
I have a 'good practice' question.
Lately I've been using a lot of functions such as this:

void Func(int Size, double *Array) {
static double *Transformed=NULL;
Transformed=realloc(Transformed, Size*sizeof(double));
// Do something from Array to Transformed
}

Now if the value of Size changes a lot between calls, the resulting prog is
poorly optimized (it reallocates each time). I'm ok with that.
Ignoring the fact that the memory is never freed, if the value of Size
changes seldom, does the call to realloc wastes time then ?
--
Guillaume Dargaud
http://www.gdargaud.net/


 
Reply With Quote
 
 
 
 
christian.bau
Guest
Posts: n/a
 
      10-18-2007
On Oct 18, 10:02 am, "Guillaume Dargaud"
<(E-Mail Removed) t> wrote:
> Hello all,
> I have a 'good practice' question.
> Lately I've been using a lot of functions such as this:
>
> void Func(int Size, double *Array) {
> static double *Transformed=NULL;
> Transformed=realloc(Transformed, Size*sizeof(double));
> // Do something from Array to Transformed
>
> }
>
> Now if the value of Size changes a lot between calls, the resulting prog is
> poorly optimized (it reallocates each time). I'm ok with that.
> Ignoring the fact that the memory is never freed, if the value of Size
> changes seldom, does the call to realloc wastes time then ?


It depends. realloc will often be clever enough to realise that it can
just use the previous block of data without any change. So if you pass
in the same Size or similar Size values (like 10000, 10001, 9999) it
will be fast. However, if a new block is allocated, all the data will
be copied from the previous block to the new block, because that is
what realloc does. That might be quite wasteful.

You might just add another variable "static int allocatedSize = 0",
compare new and old size and only realloc when it gets bigger.

 
Reply With Quote
 
 
 
 
vipvipvipvip.ru@gmail.com
Guest
Posts: n/a
 
      10-18-2007
On Oct 18, 1:28 pm, "christian.bau" <(E-Mail Removed)>
wrote:
> It depends. realloc will often be clever enough to realise that it can
> just use the previous block of data without any change. So if you pass
> in the same Size or similar Size values (like 10000, 10001, 9999) it
> will be fast. However, if a new block is allocated, all the data will
> be copied from the previous block to the new block, because that is
> what realloc does. That might be quite wasteful.


realloc tries not to copy the data, just resize the available block of
memory.
> Note that realloc() *may* move the memory allocation resulting in a different return value than ptr.


 
Reply With Quote
 
Spiros Bousbouras
Guest
Posts: n/a
 
      10-18-2007
On Oct 18, 11:28 am, "christian.bau"
<(E-Mail Removed)> wrote:
> On Oct 18, 10:02 am, "Guillaume Dargaud"
>
> <(E-Mail Removed) t> wrote:
> > Hello all,
> > I have a 'good practice' question.
> > Lately I've been using a lot of functions such as this:

>
> > void Func(int Size, double *Array) {
> > static double *Transformed=NULL;
> > Transformed=realloc(Transformed, Size*sizeof(double));
> > // Do something from Array to Transformed

>
> > }

>
> > Now if the value of Size changes a lot between calls, the resulting prog is
> > poorly optimized (it reallocates each time). I'm ok with that.
> > Ignoring the fact that the memory is never freed, if the value of Size
> > changes seldom, does the call to realloc wastes time then ?


If you're ok with the fact that the function calls realloc each time,
then which waste of time are you worried about ?

Leaving your question aside there are a couple of problems with the
function. It would be better to make Size of type size_t. You need to
make sure that the expression Size*sizeof(double) does not overflow
before you pass it to realloc.

> You might just add another variable "static int allocatedSize = 0",
> compare new and old size and only realloc when it gets bigger.


I second that apart from the fact that allocatedSize also needs to be
size_t.

 
Reply With Quote
 
Mark Bluemel
Guest
Posts: n/a
 
      10-18-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> realloc tries not to copy the data, just resize the available block of
> memory.


Does the standard enforce this? Otherwise you are simply discussing what
some (possibly all, but I doubt you could prove that) implementations do.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      10-18-2007
Mark Bluemel said:

> (E-Mail Removed) wrote:
>
>> realloc tries not to copy the data, just resize the available block of
>> memory.

>
> Does the standard enforce this?


No.

> Otherwise you are simply discussing what
> some (possibly all, but I doubt you could prove that) implementations do.


Right.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      10-18-2007
(E-Mail Removed) wrote:
> "christian.bau" <(E-Mail Removed)> wrote:
>
>> It depends. realloc will often be clever enough to realise that
>> it can just use the previous block of data without any change.
>> So if you pass in the same Size or similar Size values (like
>> 10000, 10001, 9999) it will be fast. However, if a new block is
>> allocated, all the data will be copied from the previous block
>> to the new block, because that is what realloc does. That might
>> be quite wasteful.

>
> realloc tries not to copy the data, just resize the available
> block of memory.


That depends on the malloc/free/realloc package, and is not
guaranteed. One package that goes to lengths to avoid copying is
nmalloc for DJGPP and similar, available at:

<http://cbfalconer.home.att.net/download/>

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      10-19-2007
Guillaume Dargaud wrote:
>
> Hello all,
> I have a 'good practice' question.
> Lately I've been using a lot of functions such as this:
>
> void Func(int Size, double *Array) {
> static double *Transformed=NULL;
> Transformed=realloc(Transformed, Size*sizeof(double));
> // Do something from Array to Transformed
> }
>
> Now if the value of Size changes a lot between calls, the resulting prog is
> poorly optimized (it reallocates each time). I'm ok with that.
> Ignoring the fact that the memory is never freed, if the value of Size
> changes seldom, does the call to realloc wastes time then ?


I would suspect that any decent realloc() would, once it sees that
the old size and new size are identical, simply return the current
pointer. (It must determine the old size at some point, in order
to perform its duties. Even a suboptimal "call malloc, memcpy the
buffer, and then free the original" routine needs to know the old
size.)

If you're that concerned, you can always keep track of the old size,
and skip the realloc() if it didn't change:

void Func(int Size, double *Array)
{
static double *Transformed = NULL;
static int OldSize = 0;

ASSERT( Size != 0 ); /* What do we want to do about zero size? */

if ( Size != OldSize )
{
Transformed = realloc(Transformed, Size*sizeof(*Transformed));
OldSize = Size;
}

/* Do something from Array to Transformed */

}

If you're not concerned about "wasted memory", you could even
change the realloc-condition to:

if ( Size > OldSize )

Then, it will only realloc if the buffer needs to grow.

Finally, if you don't need the current contents of Transformed,
it may be more efficient to call free/malloc instead, as this
skips the copy.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-19-2007
Kenneth Brody <(E-Mail Removed)> writes:
[...]
> I would suspect that any decent realloc() would, once it sees that
> the old size and new size are identical, simply return the current
> pointer. (It must determine the old size at some point, in order
> to perform its duties. Even a suboptimal "call malloc, memcpy the
> buffer, and then free the original" routine needs to know the old
> size.)

[...]

Very likely, but it's not guaranteed and code shouldn't depend on it.

The system needn't keep track of the requested size of an allocated
chunk of memory; the size is typically rounded up somehow, and the
system need only remember the rounded-up size. (If you requested,
say, 900 bytes, allocating 1024 bytes in malloc() and copying 1024
bytes in realloc() shouldn't cause any problems.)

Also, even if you try to reallocate the same size, I can imagine
realloc() noticing that the chunk is in the middle of a region of
mostly free space, and that it can help future allocations by
relocating it so it's adjacent to other allocated space. I don't know
whether any actual allocators do this.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
christian.bau
Guest
Posts: n/a
 
      10-20-2007
On Oct 19, 8:32 pm, Keith Thompson <(E-Mail Removed)> wrote:

> Also, even if you try to reallocate the same size, I can imagine
> realloc() noticing that the chunk is in the middle of a region of
> mostly free space, and that it can help future allocations by
> relocating it so it's adjacent to other allocated space. I don't know
> whether any actual allocators do this.


I have used implementations used for debugging that would _always_
allocate a new block on purpose. That makes bugs where someone didn't
expect a changed pointer more obvious.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
JNI:Solaris 9-Signal 11 in realloc() Mr T Java 0 11-19-2003 10:22 AM
Realloc a struct ** Henrik J C++ 1 11-10-2003 08:54 AM
Problem with malloc, realloc, _msize and memcpy Bren C++ 8 09-03-2003 11:01 PM
g++ 3.2.2 realloc bug? Jonathan.Bailleul C++ 3 08-08-2003 06:16 PM
Impossible Leak realloc Eitan Michaelson C++ 11 06-30-2003 10:33 AM



Advertisments