Re: Re: How to find a memory leak - appears to be "system" calls that are responsible

gzip and tar, almost certainly, but I'd bet unlink() is much faster than rm. As a shell command, rm means a fork() -- or two for a shell! And of course rm must ultimately do the unlink() as well.

On the flip side, my first impression on gzip vs Compress::Zlib was dead wrong. ++ for setting me straight.

Ah, the trauma of learning Perl . . .

Comment on Re: Re: How to find a memory leak - appears to be "system" calls that are responsible Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: How to find a memory leak - appears to be "system" calls that are responsible by tachyon (Chancellor) on May 15, 2004 at 08:21 UTC
That's a good point about rm. I tend to use rm -rf /dir/path/* for convenience. The first operation is a shell expansion on the files/dirs which are them fed to rm as as single list so the worst case is 2 operations. There are real limitations on shell expansion with long lists (yes I do know the workarounds). Anyway in this context I am sure (but untested, so I'm not THAT sure ;-) it would be way faster than unlink/rmdir with File::Find. For single files or known lists I do use unlink. Now I have a rationale! Thanks. cheers tachyon	[reply]

Replies are listed 'Best First'.

Re: Re: Re: How to find a memory leak - appears to be "system" calls that are responsible
by tachyon (Chancellor) on May 15, 2004 at 08:21 UTC

That's a good point about rm. I tend to use rm -rf /dir/path/* for convenience. The first operation is a shell expansion on the files/dirs which are them fed to rm as as single list so the worst case is 2 operations. There are real limitations on shell expansion with long lists (yes I do know the workarounds). Anyway in this context I am sure (but untested, so I'm not THAT sure ;-) it would be way faster than unlink/rmdir with File::Find. For single files or known lists I do use unlink. Now I have a rationale! Thanks.

cheers

tachyon

[reply]