And of course, if the given path to search is not the root directory of a disk volume, it's possible that one or more links to the given target file will be outside the search space, so adding a bunch of code to ditch out early won't help.

But assuming you don't need to worry about that kind of anomaly, you can tailor the perl script to short-circuit the find task like this:

#!/usr/bin/perl

use strict;
use warnings;

my ( $path, $file ) = @ARGV;
die "Usage: $0  search/path  data.file\n"
    unless ( -d $path and -f $file );

my ( $inode, $nlinks ) = ( stat _ )[1,3];
die "$file has no hard links\n" if $nlinks == 1;

my ( $chld, $nfound, @found );
$SIG{HUP} = sub { $nfound++; `kill $chld` if $nfound == $nlinks };

$chld = open( FIND, "-|", "find $path -inum $inode -print0 -exec kill 
+-HUP $$ \\;" )
    or die "find: $!\n";

$/ = chr(0);
while ( <FIND> ) {
    chomp;
    push @found, $_;
}

printf( "found %d of %d links for %s in %s\n",
        scalar @found, $nlinks, $inode, $path );
print join( "\n", @found ), "\n";
[download]

The above script works because the child process sends a HUP signal to the parent each time a file is found (note the double backslash to escape the semi-colon properly). The parent kills the child as soon as the expected count is reached, the child's output buffer gets flushed, and the parent can finish up right away.

I tested it on a path that would normally take 30 seconds to traverse with unix find. I watched the initial output from the find run, and created some hard links in one of the directories that would be found early in the process. The above code found those links, reported them correctly, and finished in less than 1 second.

(UPDATE: Added a "die" condition if stat returns a link count of 1 -- no need to run find in this case.)

(Another update: shuffled the code slightly so that the signal handler gets set up before the child process gets started.)