Allocated int's versus non allocated int's?

Jones
Unregistered
 
Post: #1
If I malloc'd all my ints and then freed them at the end of my functions, would I get a performance boost compared to just declaring them normally, and leaving them lying around (is there a way to free an int that has not been malloc'd), once the function has executed?
Quote this message in a reply
Member
Posts: 254
Joined: 2005.10
Post: #2
I'm no expert, but I believe the answer would be no. No performance boost what-so-ever. You might free up 2 bytes (1 byte? I'm too lazy to look it up) of memory, but I hardly think that is worth it.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
You will get a massive performance penalty. malloc() is expensive, free() ain't cheap, memory loads and stores ain't cheap. You'd just be doing a whole lot of work you don't need to.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #4
I think that you don't quite understand the difference between stack and heap memory yet.

(This glosses over some of the details, but you should get the general idea)

When your program runs, it uses a data structure called a stack to store the variables in your functions. Space is always added/removed from the end of the stack (thus the name). The basic idea is that when you call a function, it extends the stack by the amount of space needed for your functions variables. When the function exits, the stack shrinks by the same amount. This is really straightforward to do. The downside is that the data disappears after your function exits, and cannot be resized once it is created.

Dynamic or heap memory works much differently. Using malloc, you are requesting memory that is outside of your function. Because this memory can be released in a different order than it was requested, it can get "holes" in it and the operating system has to keep a map of what memory is available. The benefit of dynamic memory, is that you can wait until the program is running to allocate memory so that you have exactly as much as you need so that you aren't wasting memory or crashing because you don't have enough. Also, by using memory outside of the function that requests it, you can return a simple reference to the memory location instead of doing a copy. The downside of dynamic memory is that it is slow to request or release it.

In short, only use dynamic memory when you don't know much space you will need at compile time, or when you want to return a large amount of data.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 131
Joined: 2004.10
Post: #5
Not only what OneSadCookie and Skorche have said you are probably preventing the compiler from making some speed optimizations. If your data is dynamically allocated (malloc) then you are dealing with pointers to data. Potentially more instructions to fetch the memory location. Just using normal ints can allow the compiler to put those variables into unused registers for speed.

Not only that but it makes coding a bit more annoying having to prefix all your variables with a *.

Something you may not be aware of...
Code:
void funcVarTypes(void) {
   /* Your run of the mill variable.  Initial value can be anything in a production build.
   ** In a debug build you may find it is consistently 0 but do not assume this.  
   ** Initiallize all your variables when in doubt.  It'll save your bacon.  Memory
   ** used by this variable is reclaimed at function exit. */
   int aNormalIntegerVariable;

   /* A static variable will retain it's value between calls to the function.
   ** This initialization is only performed on the first time the function is called.*/
   static int aPersistentIntegerVariable = 0;

   /* Like aNormalIntegerVariable but the 'register' keyword gives the compiler
   ** a hint to try and place this variable into a register for speed.  It is not guaranteed to
   ** to do that though.  It's probably best to leave it to the optimizer anyway.*/
   register int aPotentiallyRegisteredVariable;

   if (aPersistentIntegerVariable == 0) {
      aPersistentIntegerVariable = 20;
   }
   else {
      aPersistentIntegerVariable = 0;
   }
}

int main(void) {

  
   funcVarTypes();
   /* aPersistentIntegerVariable should now be 20. */
   funcVarTypes();
   /* aPersistentIntegerVariable should 0 again. */

   return 0;
}
Quote this message in a reply
Jones
Unregistered
 
Post: #6
Well thanks for your suggestions guys, It seemed like a waste of coding time anyway. Smile
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #7
dynamic memory is evil Rasp

Seriously, using automatic variables ensures a logic approach to defining scopes for variables and passing stuff in and out of functions

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Jones
Unregistered
 
Post: #8
Najdorf Wrote:dynamic memory is evil Rasp

Seriously, using automatic variables ensures a logic approach to defining scopes for variables and passing stuff in and out of functions

And believe me, I believe you. ^^
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  C: Global Variables versus Parameters Lizard Man 10 6,249 Jan 13, 2010 08:22 PM
Last Post: Lizard Man
  NULL versus 0 pointers? WhatMeWorry 14 7,246 Apr 6, 2005 05:42 AM
Last Post: Andrew