On Sun, Mar 9, 2014 at 11:59 AM, Steve Tolkin <[email protected]>wrote:
> Since I can just set a constant value
>
Aha, this suggests using that optimization in the loop form as well, since
you don't care about the Count.
$aoh[$_]{$data[$_]}* ||= *1 foreach 0 .. $#data;
forces the auto-vivication as needed but does not re-write existing values,
will save time on the repeats.
That might save a lot more than 1% if you have high # repeats?
(Someone suggested this upthread?)
I wanted to try Bill's idea (see below) of using slices, something like
> this.
>
> $aoh[0..$#data]{@data} = 1;
>
> But this did not work. Something like this ought to work since the number
> of hashes will always equal the number of data elements. But I cannot get
> the sigils right.
>
>
>
> Is there a way to do the above?
>
I don't think so.
One hopes this higher degree of APLish parallelism will be in Perl6.
In general, performance on small files on PC has little predictive value
for actual performance (possible IO bound) on server. Of course, if the
server has good storage subsystem and file was recently written so still in
OS or subsystem cache, it might NOT be IO bound there while being so on PC
!
You could TRY doing Array slurp on the AIX server (with permissive
ULIMITs), it will be either amazingly good or amazingly bad. Trading
storage for speed sometimes works, and sometimes makes things worse.
Pulling qr/$comma/o out of the loop shouldn't change behavior, the runtime
should detect that $comma is unchanged. It does not avoid the RE engine
being invoked by split() to find commas.
Slurping into a scalar and using index(), substr() instead of split will
avoid not only RE engine execution but also all malloc/copying. This would
be old-school loop coding looking like the C char* version of the code,
doing alternate/nested scan for '\n' and ',' is the one way to change the
behavior entirely.
Might as well write it in C and get final speed boost.
(These are the sort of loops i'd code using Dijkstra Loop Invariants to
prove i'm not Off By One, since edge test cases are gnarly. I resort to
that about once a decade.)
--
Bill
@n1vux [email protected]
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
