in reply to system calls vs perl functions: Which should be faster in this example?

According to my lsof's manpage, that's not what the -c option does:

This option selects the listing of files for processes executing the command that begins with the characters of c.

That filters by the name of the command, not the name of the open file.

But your lsof|grep example and the Perl one should have the same bahevious and should be comparable. I am not sure why they are so different. One important difference is that you are capturing output with backticks in one case and not in the other.

You should also be aware lsof's reporting of filenames may not always be reliable. Once you open a file, the kernel forgets what name was used to open it and only remembers which device and inode was opened. If the file has multiple names (hard links) then it is in fact impossible in general to know which one was opened. lsof gets around this by searching for the name in the kernel's directory name lookup cache where the kernel remembers this information in case it needs it again. But it is a cache and it might be flushed. Does your application permit finding exactly which files you are interested in and searching for those files in the lsof output by device & node number?

  • Comment on Re: system calls vs perl functions: Which should be faster in this example?

Replies are listed 'Best First'.
Re^2: system calls vs perl functions: Which should be faster in this example?
by machinecraig (Monk) on Dec 05, 2005 at 20:29 UTC
    Argh. You're exactly right about the lsof -c option. My actual requirement is to search for files opened by a particular process - I somehow mungled this up while writing up my question. I suppose that's what I get for skipping my coffee this morning. :-) Good catch - and interesting info re: lsof's reporting of filenames. Also - that's a good point about the use of backticks. I'll switch to backticks for my other system calls and see how the numbers change.