My experience with OSX is that after a program exits, the OS keeps stuff in memory that "might be used again soon", but all of this memory is actually free to be re-used should any program ask for it. A memory "purge" clears out all this stuff, but purging memory doesn't make a working difference, as far as I see.

As well as the links above, there is a useful discussion here.

I hope that's of some help

Its FAQ :)

1. Why it's stupid to `use a variable as a variable name'
2. A More Direct Explanation of the Problem
3. What if I'm Really Careful?

Tutorials: Variable Scoping in Perl: the basics, Coping with Scoping , Mini-Tutorial: Perl's Memory Management, Lexical scoping like a fox, Read this if you want to cut your development time in half!

Good luck

Sorry if I am wrong. It is a pseudo code that I have posted. In the real code all the variable names are not the same what I have given here. So if you are telling me that $var1 ideally not correct to assign a variable name, then I am not doing that thing. Please correct me if I am not able to understand what you are telling.

Well, you posted some code ... which you didn't say was pseudocode ... which isn't written to cope with scoping ... three programs pasted into one file , no indentation ...

All I was trying to say is read these tutorials and learn from them, learn about scoping, learn about perls memory management...

But as you said, its pseudocode , so... well, I really don't have anything more specific to add

Have a nice day , I wish you all the best

The short simple answer is to fork off the memory intensive operation and collect the results thru a pipe or some other perlipc. When you use threads, there is always the chance for memory accumulation. When you fork, you get a new pid, and when that pid is destroyed, ALL memory is returned.

For example, the following code was posted awhile back to demonstrate how easy it is to fork and collect data.

#!/usr/bin/perl
use strict;
use warnings;
use Parallel::ForkManager;

my $pm = Parallel::ForkManager->new(2);

$pm->run_on_finish(
    sub {
        # result from the child will be passed as 6th arg to callback
        my $res = $_[5];
        # p $res;
        print "$res\n";
    }
);

for (1..3) {
    $pm->start and next;
    # from here and till $pm->finish child process running
    # do something useful and store result in $res
    my $res = { aaa => $_ };
    # this will terminate child and pass $res to parent process
    $pm->finish(0, $res);
}

$pm->wait_all_children;
[download]

Memory issues are usually difficult to track. How do you seriously expect us to help you on such issues if you don't post the real program but only pseudo-code, or don't post, at the very least, a modified/simplified program that exhibits the same behavior as the one you are describing? The code you presented is poorly written in terms of memory management and variable scoping and a number of other aspects (I would simply not hire someone who shows to me such code with no indentation whatsoever), but I don't believe for one second that this code would continue to clutter memory after the program has completed.

Do yourself a favor: remove all these silly undef function calls and use correctly scoped lexical variables, use strict;, use warnings;, indent your code correctly (with whatever indenting style you prefer), give variables meaningful names, learn how to use arrays and hashes, rather than things like

$var1=$1;$var2=$2;$var3=$3;$var4=$4;
[download]

Sourav, I apologize on behalf of the group for some of the “answers” (sic ...) that you have lately received here.   It is true that this is not a particularly well-designed program.   However, it may also be true that you did not write it and/or that there is no business justification for a rewrite, given that, as you say, it is doing a complex time-consuming thing and it works.   So, here are two specific tricks that I use in this kind of situation:

1. Spin off a subset of the work into a per-request child process, following more-or-less exactly the excellent example previously given.   The operating system will tear-down a process completely.   (Note that threads are not equivalent since all threads run in the context of a parent process.)   Each unit of work needs to be self-contained with basically no need to communicate or to maintain any kind of global-state betwixt them.
2. Parcel the primary unit or units of work into subroutines, and move as many variables as possible into local scope within those subroutines, parameterizing them as need be.   Studiously avoid globals.   The interpreter will clean-up the local variables of a subroutine, with a few caveats regarding memory-references and circular-references that I hope we will not need to get into here.

Both of these things – especially the first – are changes that can usually be wrapped-around “logic that works” with a reasonably small risk of de-stabilization.   Nevertheless, results should be aggressively (re-)tested.

Sourav, I apologize on behalf of the group for some of the “answers” (sic ...) that you have lately received here. It is true that this is not a particularly well-designed program. However, it may also be true that you did not write it and/or that there is no business justification for a rewrite, given that, as you say, it is doing a complex time-consuming thing and it works.

I have to strongly disagree with that.

First, who are YOU to apologize on behalf of others? Come on, who do you think you are? You have the right to disagree and please do so if you wish, but don't apologize on behalf of others, this is just ridiculously stupid.

Second, the program presented is poorly written, to say the least. Saying that fact is an acceptable “answer” (sic ...), whether you agree or not.

Third, judging from the OP's post, there is a problem, it does not work properly. So please don't say it works. It obviously doesn't.

Fourth, when you have such a messy program, there will necessarily be one day where you have to refactor it, may be it is time. Or maybe you want to do it next time. But you know it will have to be done.

Fifth, the OP stated that the program presented is not the real one, but some pseudo-code; nobody knows if this pseudo code exhibits the same problem as the real code. Should I care? I don't see why...

I could add another half a dozen other objections to your post, but I think that I have made the point clearly.