Hi monks,
Thanks a lot for the guidance!!!   I am here to provide more info regarding the issue.

The version of perl in the servers are
1) server where the process hogs more memmory - v5.8.0 built for PA-RISC2.0-thread-multi-LP64
2) The other server - v5.8.0 built for PA-RISC1.1-thread-multi

Both the servers are having the same OS HP-UX B.11.00. I have verified that the test script I run is the same on both machines, which is as follows:.

#!/usr/local/bin/perl
use File::Find;

sub findtime
{
if ( -f "$File::Find::name" && "$File::Find::name" =~ /.*\.txt/i)
{
}
}

while (true)
{
sleep 3;
find(\&findtime,"/test");
}

and the number of files( both total and *.txt files) under the directo
+ry /test is the same. Additionally, i have observed that the memmory 
+hogged by the server(which has the issue), apart from being huge at t
+he initiation itself, grows with time.

I have done a diff between the File/Find.pm files of the two servers a
+nd noticed that following are the differences.( lets call the server 
+hogging memmory as s1 and the other as s2)

s1
--
17c17
<     find(\&wanted, @directories_to_seach);
---
s2
---
>     find(\&wanted, @directories_to_search);
----------------------------------------------------------------------
+---
s1
--
42c42
< order they are given.  In essense, it works from the top down.
---
s2
--
> order they are given.  In essence, it works from the top down.
----------------------------------------------------------------------
+----
s1
--
571c571
<     local($dir, $name, $fullname, $prune);
---
s2
--
>     local($dir, $name, $fullname, $prune, $_);
----------------------------------------------------------------------
+-----
s2
--
702a703
>           $_ = $name if $no_chdir;
[download]

Apparently, the Find.pm in s1 looks like to have undergone some manipulations, by the root, which is highly unlikely. Please let me know if I can provide any further info, before reaching some conclusion.

janitored by ybiC: Removed frowned-upon <pre> tags, minor format tweaks for legibility