I would have to check, but I thought that splice was only
slow if you have to move the array around. But I don't
know whether pulling from the beginning of the array has
been optimized. And (like jcwren) I am too lazy to
benchmark it at the moment. In any case shift is fast
and has the benefit of avoiding tracking indices. (Note
that you had a bug in your code which jcwren caught?
Yes, I am talking about that.)
while (@big_array) {
my $href;
@$href{'title', 'author', 'link'} = map shift(@big_array), 1..4;
push @structs, $href;
}
This might be faster than your sneaky trick. It might be
slower. It certainly has fewer indices.
Also the cost of reverse is overstated. You have just
walked through a list of n things in Perl. You then want
to reverse a list of n/4 things. What is the relative cost
of those two operations? Right.
Pick up good material on optimization. Such as this
sample
chapter from Code Complete. Or RE: Efficient Perl Programming. You will
find that experienced people understand that getting
maintainable code with good algorithms can result in better
overall speed wins than trying to optimize every line.
Now noticing the splice, that matters. If it isn't
optimized then that is an order(n) operation n times -
which is n^2 and therefore is likely to be slow. But one
reverse at the end is an order n operation once. Should
the body of the loop be slightly more efficient from doing
the slice rather than repeated manipulation of indices
(something I would have to benchmark to have a feeling for
either way) then your attempt to optimize would actually
lose.
To summarize, don't worry about slow operations, worry
about bad algorithms. A slow operation inside a loop may
matter. A slow operation outside a loop which speeds up
the loop can go either way. An order n (or worse)
operation inside a
loop - that is the only one which should cause you to want
to care up front about optimizing the structure of the
code!
EDIT
I had messed up the final paragraph. |