Warp wrote:
>   Odd question, given that you answered it even before you asked it.

I knew I'd get this response from someone. I was just worried about the 
non-new declaration of arrays and variables, but I am clear on those now.

>   If you deleted it, you would have more deletes than news, which would
> break the "for each new, delete" rule.

Indeed. This happened with my maze game, and I got a warning about it.

>> I didn't use a "new" flag to initialize the [static] array. Is the 
>> memory used by that array freed after the program is terminated?
> 
>   No. It's freed when it goes out of scope.

Cool. Thanks!

Sam

Post a reply to this message

> I mean when I monitor my system's memory usage, more memory is being 
> used AFTER I close my program. But after several runs, the memory is 
> returned to an earlier state.
> 

I don't think the problem is in your program, then. When it does not run 
anymore, it does not use memory anymore, at least on modern OSes... 
Perhaps you could try to find a way to monitor the memory per process, 
rather than the whole.

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:

>> I mean when I monitor my system's memory usage, more memory is being 
>> used AFTER I close my program. But after several runs, the memory is 
>> returned to an earlier state.
> 
> I don't think the problem is in your program, then. When it does not run 
> anymore, it does not use memory anymore, at least on modern OSes... 
> Perhaps you could try to find a way to monitor the memory per process, 
> rather than the whole. 

No, I mean the program uses more memory when I run it, and the memory 
consumption is slightly higher after I quit than it was before I opened 
the program. It does this with other apps, too (Firefox). I don't think 
it's a problem with my program, if other programs are doing it too. 
Unless, of course, Firefox is buggy (which it might be).

Sam

Post a reply to this message

> Vincent Le Chevalier wrote:
>> Everything that wasn't new-ed.
>>
>> Normally the OS frees the memory used when the program ends anyway... 
>> So I don't understand exactly what you observe in your game. You mean 
>> it takes more memory when it runs for the 6th time than it took the 
>> first time?
> 
> I mean when I monitor my system's memory usage, more memory is being 
> used AFTER I close my program. But after several runs, the memory is 
> returned to an earlier state.
> 
> Sam
> 
Two words: disk cache.

Post a reply to this message

Memory can be free, but not available, it can
be fragmented, some other process might
have put a small amount of data in a big block,
the block is mostly empty, but is GC later by
the system after it runs out of fresh memory,
so after many levels the system packs the
memory in tighter, and the next GC takes
longer to be required because the data is
now assigned to the same blocks instead of
scattered blocks.

Post a reply to this message

"Samuel Benge" <stb### [at] THIShotmailcom> wrote in message
news:4702e940$1@news.povray.org...
> Vincent Le Chevalier wrote:

> >> I mean when I monitor my system's memory usage, more memory is being
> >> used AFTER I close my program. But after several runs, the memory is
> >> returned to an earlier state.
> >
> > I don't think the problem is in your program, then. When it does not run
> > anymore, it does not use memory anymore, at least on modern OSes...
> > Perhaps you could try to find a way to monitor the memory per process,
> > rather than the whole.
>
> No, I mean the program uses more memory when I run it, and the memory
> consumption is slightly higher after I quit than it was before I opened
> the program. It does this with other apps, too (Firefox). I don't think
> it's a problem with my program, if other programs are doing it too.
> Unless, of course, Firefox is buggy (which it might be).
>
> Sam

Your OS could be keeping the most recently used libraries in memory in case
they are going to be called again.

Post a reply to this message

Samuel Benge wrote:
> No, I mean the program uses more memory when I run it, and the memory 
> consumption is slightly higher after I quit than it was before I opened 
> the program.

I think the basic problem here is what you mean by "memory consumption". 
Memory doesn't get consumed, and all of it is always there. It's just a 
question of who happens to be using it at the moment. Once your program 
exits, your program isn't using the memory any more. There might be 
something in a cache, or the kernel may have a bug in it that's not 
marking the memory as available after your program stops using it.

But the question of "how do you know the memory is 'consumed'?" would 
likely provide clues towards answering the question of who is using it.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> But the question of "how do you know the memory is 'consumed'?" would 
> likely provide clues towards answering the question of who is using it.

  That's indeed quite relevant.

  The amount of available "free memory" is quite an irrelevant number in
any modern OS (and most of the older ones too). Even Windows. That number
doesn't really say anything. IMO it could and should be removed from the
basic user interface because it only causes confusion and serves no useful
purpose. Even some very experienced users get confused by that number.
Usually many people get worried if the amount of free memory is very low,
even though there's often absolutely nothing to it.

  Sure, the number is telling the amount of memory currently not used by
anything. However, knowing the amount of memory not used currently by
anything is basically useless information because it tells you nothing
about the state of the system. It does *not* tell how much memory will
be available for a program you will be next starting. It does *not* tell
you that the system is running out of memory and that something is wrong
because of that.

  Most OSes will use available free memory for internal things. This is
usually pretty "light" form of usage of memory in that immediately when
a new process requests more memory than is currently unused, that memory
used by the OS for its own things will be immediately freed for the process
to use.
  It may very well happen that the OS reports that there's only 1MB of free
memory in a 1GB system, yet when you start a program requiring half of a
gigabyte of memory, it runs smoothly without even the slightest bit of
swapping or anything. The OS simply stopped using part of that memory and
freed it for the process to use.

  That's why the "memory free" number doesn't really say anything.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood wrote:
> Memory can be free, but not available, it can
> be fragmented, some other process might
> have put a small amount of data in a big block,
> the block is mostly empty, but is GC later by
> the system after it runs out of fresh memory,
> so after many levels the system packs the
> memory in tighter, and the next GC takes
> longer to be required because the data is
> now assigned to the same blocks instead of
> scattered blocks.
> 

Now that makes sense!

Post a reply to this message

Ross wrote:
> Your OS could be keeping the most recently used libraries in memory in case
> they are going to be called again.

This also makes sense.

Post a reply to this message