discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with NSAutoreleasePool in GNUstep


From: Nicola Pero
Subject: Re: Problem with NSAutoreleasePool in GNUstep
Date: Mon, 3 Dec 2001 14:14:23 +0000 (GMT)

> Richard,
> 
> thanks for the response.
> 
> We tried with +freecache, still the memory used by the program is not going
> down.
> 
> I still could not get why memory usage is not coming down after [pool
> release]. In OpenStep the memory usage does come down?
> 
> This problem is not with particular machine, it is coming on all machines

I tried your code ... hacked it to run on my debian gnu/linux box - and I
get -

nicola@didone:~/hh/A$ ./shared_obj/ix86/linux-gnu/gnu-gnu-gnu/memory 

Dic 03 15:02:03 memory[2337] Memory Usage at the beginning: VmSize:         
3928 kB

Dic 03 15:02:03 memory[2337] Memory Usage before allocation: VmSize:        
4496 kB

Dic 03 15:02:05 memory[2337] Memory Usage after allocation: VmSize:        
29604 kB

Dic 03 15:02:05 memory[2337] Memory Usage after removal: VmSize:           
29604 kB

Dic 03 15:02:05 memory[2337] Memory Usage after release of the pool: VmSize:    
    8872 kB

Dic 03 15:02:05 memory[2337] Memory Usage after freeCache: VmSize:          
4492 kB

so I don't see the effect you see ... memory is returned on my system.


Anyway - the suggestion you got from other people is correct - if your
application reaches a peak memory usage of 1 Gb or whatever - did I hear
correctly ?, are you sure you can't rework your application so that the
peak memory usage is less than that ?  It's going to be healthy even not
considering this question.  I think you really need to cut that peak down
if you can.

Typically, if you have a loop, you need to recreate the autorelease pool
periodically, as in

/* -*-objc-*- */

#include <Foundation/Foundation.h>
#include "OIProcessStatistics.h"

void printMemory (NSString *when)
{
  NSLog (@"Memory Usage %@: %@", when,
         [OIProcessStatistics getCurrentProcessMemoryUsage]);  
}


int main (void)
{
  NSAutoreleasePool * pool = [NSAutoreleasePool new];
  
  printMemory (@"at the beginning");
  
  {
    NSAutoreleasePool * poolInner = [NSAutoreleasePool new];
    NSMutableArray *theArr = [NSMutableArray new];
    int i, j;
    
    printMemory (@"before allocation");

    for (i = 0, j =0; i < 100000; i++, j++)
      {
        if (j = 10000)
          {
            DESTROY (poolInner);
            poolInner = [NSAutoreleasePool new];
            j = 0;
          }
        [theArr addObject:
                  [NSString stringWithFormat: 
@"Helllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllooooooooooooooooooooooooooooooooooooo
 %d",
                                           i]];
      }
    
    printMemory (@"after allocation");
    
    [theArr removeAllObjects];

    printMemory (@"after removal");

    RELEASE (theArr);
    DESTROY (poolInner);

    printMemory (@"after release of the pool");

    [NSAutoreleasePool freeCache];
    
    printMemory (@"after freeCache");
  }

  DESTROY (pool);
  return 0;
}

this example is not particularly meaningful because you are not creating
many temporary objects inside the loop _ in a real world application you
would probably do something inside the loop, generate a lot of temporary
objects, and releasing the pools has a greater effect on memory
performance.  I'm not sure how much obvious is what I've been saying :-)
but I thought I would give a practical example code in case you felt the
suggestion of recreating autorelease pools more often was too vague.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]