• chdir
- Changes the working directory to EXPR - you can't do this with system("cd $dir"); or $ENV{PWD} = $dir; - chdir looks like a good option :o)
• opendir
- Opens a directory named EXPR for processing by readdir, telldir, seekdir, rewinddir, and closedir. - what else could you use to do that?
• readdir
- Returns the next directory entry for a directory opened by opendir. I guess you could fudge that up by using ls, but using readdir from within Perl is more simple and efficient.
• closedir
- Closes a directory opened by opendir - how could you do that?
• symlink
- sure, you could do system ("ln -s $orig $link"); but why complicate things, and why ask someone else to do something you can easily do yourself and then know the result straight away?

• open
- there are many ways to read data out of file, using open within perl is certainly a good one. Using backticks and cat or something like that would not be likely to win you any "well done" prizes.
• read
- Attempts to read LENGTH characters of data into variable SCALAR from the specified FILEHANDLE.
• close
- Closes the file or pipe associated with the file handle - again, what are you proposing to do this with?

Also, opendir and open don't do the same thing. You sure you're not prematurely optimizing?

Benchmarking issues apart, not only opendir and open don't do the same thing: more precisely the OP gives two lists of items presenting them, for some strange reason, as "examples system operators" and "built in functions" respectively. But no item from the first one is equivalent to any of the second one for any reasonable acceptation of "equivalent"!

Also, all of those items represent a built in functions with that name, that actually do system calls. So I really don't know what he may have in mind, but I wonder how he could even cmpthese() stuff that bears no resemblance to each other. Maybe he's not (yet) prematurely optimizing, but he seems definitely to be concerned about premature optimization, which we all know, is Bad(TM).

    When some one wants to you use the OS related operations, they will try to use "system" function. It will be easier for them to use. But, when you use those functions, it will be executed by the shell, and the value will be returned. That will definitely increase system load. Instead of that you can use the builtin functions which is available in perl itself. But, here you need to find out the appropriate module and have to use the correct function. When you go for the builtin functions, it wont take much time compared to the system functions.

But, when you use those functions, it will be executed by the shell, and the value will be returned.

Really?

q:~ [10:07:26]$ ps U blazar
  PID TTY      STAT   TIME COMMAND
11831 ?        S      0:00 sshd: blazar@pts/0
11838 pts/0    Ss     0:00 -bash
11857 pts/0    R+     0:00 ps U blazar
q:~ [10:07:32]$ perl -e 'system qw/sleep 600/'

[1]+  Stopped                 perl -e 'system qw/sleep 600/'
q:~ [10:08:09]$ ps U blazar
  PID TTY      STAT   TIME COMMAND
11831 ?        S      0:00 sshd: blazar@pts/0
11838 pts/0    Ss     0:00 -bash
11908 pts/0    T      0:00 perl -e system qw/sleep 600/
11909 pts/0    T      0:00 sleep 600
11922 pts/0    R+     0:00 ps U blazar
[download]

I don't see additional shells...

(To the benefit of the OP) this "detail" apart, indeed system calls are expensive.

Perhaps you could benchmark this and report back.