Re^3: Performance problems on splitting long strings

You can simplify the calls to the anonymous subroutines. ...

Thank you for your comment, Jim.

And, yes, I wanted to write something like that, and that the reason why I built references to anonymous subs in the first place, rather than simple named functions. But for some reason, I got something wrong in the syntax for calling the subs in cmpthese, I am not sure to remember exactly, but I think I first did something like:

regex1  => $regex1->(),
[download]

which gave compile errors. The first quick way I found to make it work was to wrap the function call in a sub block like this:

regex1  => sub {$regex1->()},
[download]

I realize that this is not the most elegant construct, but once it worked, I was happy enough to get my results and I was too tired, at around 2 a.m., to spend more time investigating further how to simplify the calls.

And yes, I was sort of expecting unpack() to be faster, but it is still better to try it to be sure.

Comment on Re^3: Performance problems on splitting long strings Select or Download Code

Replies are listed 'Best First'.
Re^4: Performance problems on splitting long strings by AnomalousMonk (Archbishop) on Feb 01, 2014 at 19:55 UTC
... I think I first did something like: `regex1 => $regex1->(),` which gave compile errors. You may know this already, but `$regex1->()` is a function invocation. The `{ ... }` anonymous hash reference constructor tries to treat the first item returned by this function call as a value to be paired with, in this case, the key `'regex1'`. If the number of items in the list consisting in the grand total of all such keys and invocations is odd, the constructor will fail with an "Odd number of elements in anonymous hash ..." error. If it is even, the hash constructed will be a meaningless mish-mosh unless the referenced functions are designed to return valid hash elements, which in this case they are not. The expression `sub {$regex1->()}` produces a single code reference, which pairs as a value quite happily with any key string. It is redundant in that it simply wraps the invocation of another code reference, but this point has already been covered.	[reply] [d/l] [select]
Re^5: Performance problems on splitting long strings by Laurent_R (Canon) on Feb 01, 2014 at 23:24 UTC
Thank you, AnomalousMonk, for your very useful input. Yes, looking at it retrospectively, I clearly realize that it was a bit silly on my part to try to pass a function invocation, rather than a simple code reference, to the benchmark module. I am definitely not proud of that stupid error, but I thought it might be useful to others for me to explain what I originally did wrong. I wrote a couple of tutorials in French on some specific uses of Perl, and, in them, I am quite often proposing an initial wrong answer before giving out the right one, as I think trying something wrong is at least as useful as getting the right one from the start. Your explanation on my original error serves the same purpose, thank you for that (and, let me be clear on that, I am not trying to claim that it will be useful to others only, my description of my original error was hopefully for the others' benefit, your explanation is useful to others, I think, AND to me as well). My only excuse, if any, is that it was very late at night and I was tired, so that my ideas were a little bit blurred by tiredness (not to mention the couple of wine glasses I had earlier for a small celebration at my photo club). Then, as I already said, I was in a bit of a hurry to try to get the results I was looking for and wrapping the invocation in a `sub {}` construct was the fastest solution I found to get a clean compile and usable results. Thank you again for the time you took on this post, as well as on your earlier post on the same topic. Cheers.	[reply] [d/l]
Re^6: Performance problems on splitting long strings by AnomalousMonk (Archbishop) on Feb 02, 2014 at 08:29 UTC
... trying something wrong is at least as useful as getting the right one from the start. I often see questions on this site in the form "What happens if I do X?" and the answer I am often tempted to give is "Well, what happened when you did X?" Unfortunately, this answer is usually a bit too brusque to offer a novice and one tends to be more circumspect. I agree that play is always valuable for learning, and Perl makes playful interaction fairly easy. BTW: I didn't mean by my reply to offer you instruction for I do not suppose you need it, but only to offer a general explanation.	[reply]
Re^4: Performance problems on splitting long strings by Jim (Curate) on Feb 01, 2014 at 22:25 UTC
And yes, I was sort of expecting `unpack()` to be faster, but it is still better to try it to be sure. Indeed. I certainly didn't mean to suggest your benchmark test wasn't a splendid idea. I only meant that, in this case, the outcome of the benchmark test was consistent with one's rational expectation based on one's understanding of `unpack()` and its raison d'être. After all, the Perl FAQ states: `C:\>perldoc -q fixed \| head -5 Found in C:\strawberry\perl\lib\perlfaq5.pod How can I manipulate fixed-record-length files? The most efficient way is using pack() and unpack(). This is faste +r than using substr() when taking many, many strings. It is slower for ju +st a few. C:\>` [download] Jim	[reply] [d/l] [select]