The reason why I use local $/ instead of my $/ is the difference between how local and my work.

The keyword local has been around for a long time, way before the keyword my (which was introduced only after Perl 5).

The difference is that local is run-time scoping, while my is compile-time scoping. Local $/ will first push the value of current $/ onto the stack, and then when the code leave the scope, automatically restores its previous content. my $/ will not work here, it will give you a perl compilation error, any $-punctuation variable will have to be localized with local, it's a limitation (or feature?) of perl. local keyword reuses a variable already exists in the global context.

This method is not efficient if you have lots of data (hundreds of Mb) pumping out from another process, because it will have to allocate memory to hold the input.

In addition to the reply from Roger above, the node Perl Idioms Explained - my $string = do { local $/; <FILEHANDLE> }; from jeffa and the discussion that follows provides an excellent overview of this idiom.

 

perl -le "print+unpack'N',pack'B32','00000000000000000000001010000011'"

This is only advisable if the input data will fit into the available memory without compromising other processes at the same time.
You don't want the system to start paging heavily or exhaust memory just for the sake of having all data in memory at once.

Slurping files can sometimes be advantageous.
Other times using read() or sysread() to read large blocks of data might do the trick.
Personally I still find myself using a simple  while (<FH>){...} for most jobs, from logfiles to multi-gigabyte datasets.

Cheers,

BazB