Re: Speeding up named capture buffer access

[moritz]

My first attempt would be to use hash slices:

($h, $mn, $s) = @+{qw(h mn s)};

and see if it's actually faster.

[SBECK]

Good news/bad news.

The number of calls didn't change at all (I didn't really expect it too).

Oddly enought though, the time required did decrease significantly, so I'll definitely switch to using hash slices. Probably some internal optimization that I wasn't aware of.

I'm still going to try to reduce the number of calls though... that's where the big speedup would come.

[BrowserUk]

If you are going to (have to?) immediately assign the named captures to local/global variables (rather than using the named captures themselves), wouldn't you be better off avoiding the overhead of the ties completely by sticking with unnamed captures?

I just can't see any advantage in:

$string =~ $re;
($h,$mn,$s) = ($+{'h'},$+{'mn'},$+{'s'})

Over (with unnamed captures):

($h,$mn,$s) = $string =~ $re;

Just a not inconsiderable overhead.

[SBECK]

I can't do that for the exact reason that I want to use named capture buffers. The regular expression is very complicated. It's basically of the form:

     $re = qr/($re1|$re2|...|$reN)/;

where each of the pieces may match a valid time. But some may match a partial time (perhaps only hours and minutes), some may match a 24-hour time and others may include an AM/PM string, some may include timezone information, and because there are so many ways to express times, some of them may even have the order of the fields changed, so I wouldn't want to depend on the order of the matches always being ($h,$mn,$s).

So, using numbered matches, I could do something like:

     foreach $re ($re1,$re2,...) {
        ($h,$mn,$s) = $string =~ $re;
        last  if ($h,$mn,$s)
     }

except that that won't work because I'm relying on the order of matches (and assuming that there will always be an $h match, etc).

With named capture buffers, I can do this so elegantly. I define each regexp, name the capture buffers (in whatever order they come in) and the named buffer will contain all the ones that actually matched. Maintaining the complicated regexps in Date::Manip is about 100 times easier now!

[vitoco]

I don't see anything wrong with:

  %tmp = %+;

Did you try/get the number of calls of this?

BTW, I first thought about the following as in update/append mode for hashes:

  @tmp{ keys %+ } = values %+;

but I could predict that the number of calls should increase.

[SBECK]

There's not anything 'wrong' with it (i.e. it works), but now, in addition to 3 calls to FETCH for every key, there are also calls to FIRSTKEY and NEXTKEY, so the number of calls increases, and it's marginally slower.

Basically, if there are 3 named buffers (and in the real-life module, there's usually a lot more than that), there have to be 3 calls to FETCH, but by doing the work at the level of my module, it is constantly doing a FETCH and returning to my module, then calling FETCH again, over and over.

I want to have a Tie::Hash method which will return the entire hash. Then there will be only a single call to a Tie::Hash::NamedCapture routine (which will then call all of the FETCH'es internally, but since this is all c code, it should be a lot faster).

Unfortunately, I'm fairly certain it doesn't exist at this point, so I'm just experimenting with ways to speed up what I've got.