How about the following?

use strict;
my $target = shift || 'word';
my $re = qr/a=<(.*?$target.*?)>/;

while( <DATA> ) {
  if (index($_, $target) >= 0 && /$re/) { #short-circuit regex!
    print "[$1]\n";
  }
}
[download]

The poor, oft-ignored index function will filter out lines that don't contain 'word' at all, probably w/fewer cycles than running a regexp. Your mileage may vary, of course.

The index() isn't really all that much faster than a regexp. BrowserUK was testing this once, I played with the benchmark and noticed that the index test was a percentage point faster. At this point I'd prefer people just recommend the regexp since it is as fast and is notationally less complex.

Cool beans if so! Sounds like a good candidate for a Meditation.

Hanlon's Razor - "Never attribute to malice that which can be adequately explained by stupidity"

(?>.*?$target) may be what you want, but I'm not sure it will make any difference once you've switched to using [^>]* in the later part.

Depending on the complexity of your $target and your data, you may find a gain by breaking your search up:

my $target = shift || 'word';
$target = qr/$target/;
my $re = qr/a=<([^>]+)>/;
while( <DATA> ) {
    next unless /$re/;
    my $s = $1;
    print "[$s]\n" if $s =~ /$target/;
}
[download]

use strict;
use Benchmark qw/timethese cmpthese/;
# use re 'debug';

chomp(my @lines = <DATA>);
my $target = shift || 'word';
my $re_positive_lookahead  = qr/^a=<(?=.*?word)/;
my $re_loose = qr/a=<(.*?$target.*?)>/;

cmpthese( timethese(1000000, {
        'Match_L' => '&Match_Loose',
        'Match_P' => '&Match_PLAhead_plus_Substr',
    }) );

sub Match_Loose {
    foreach (@lines) {
        if (/$re_loose/) {
            my $word = $1;
        }
    }
}

sub Match_PLAhead_plus_Substr {
    foreach (@lines) {
        if (/$re_positive_lookahead/) {
            my $word = substr($_, 3, length($_)-4);
        }
    }
}

__DATA__
a=<swords>
a=<wordy>
b=<rappinghood>
a=<thisword>
b=<thatword>
a=<foreword>
b=<junk>
a=<nothing>
b=<word>
b=<wordplay>
b=<end>
[download]

Benchmark: timing 1000000 iterations of Match_L, Match_P...
 Match_L: 31 wclock secs (31.16 usr +  0.00 sys = 31.16 CPU) @ 32092.4
+3/s
 Match_P: 27 wclock secs (27.64 usr +  0.00 sys = 27.64 CPU) @ 36179.4
+5/s

           Rate Match_L Match_P
Match_L 32092/s      --    -11%
Match_P 36179/s     13%      --
[download]

The observation is that positive lookahead combined with substr is about 12% faster than straight regexp with capture, which is not an insignificant speed improvement.

You are testing a highly sanitized version of the problem. The OP reduced it a barebones example. Surely the OP's logs do not begin with, nor even contain, the data shown, making it more complex to use substr to grab the right chunk of string. Secondly, your speed gain disappears entirely when you remove trailing backtracking from the loose regex as mentioned earlier. Try it with the this regex:

my $re_loose = qr/a=<(.*?$target[^>]+)>/;
[download]

Last, but most certainly not least: It is far too easy to reach unjustfied conclusions when benchmarking.

Perhaps the simplest way is to take two bites at the cherry.

if( $string =~ m[^a=<([^>]*)>] and $1 =~ m[$target] ) {
    # Do something
}
[download]

This is often, though not always, the quickest approach.

From the rest of the post however, I get the impression that this is just something you do every now and then, and that its just a little slow and maybe you have to go make a cup of coffee while it runs.

The two are very different. If you are hunting this data regularly in a constrained environment, there are numerous techniques you can use to boost the performance of your search, including sorted character and pair indexes etc.

On the other hand, these will take effort to implement. If you're just getting bored of waiting and want a faster regex, the one you put in the update is probably going to be about it. You won't be able to remove the backtracking entirely, in a worst case example imagine you're looking for "teatea" in the string "teateteatea". Its going to backtrack no matter what regular expression you use to pull off the match.

The other viable alternative is to push all the data into a decent database and let it worry about it. All depends on how often the data changes and how often you do the searches.

It's a pity that you didn't specify those factors :/