On Wednesday, 20 June 2018 at 05:49:15 UTC, Dukc wrote:
On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote:
Is there anything I can do to improve zip, before I go ahead
and change to the faster but slightly less readable enumerate?
The problem might be that zip checks both arrays for empty
during each step, enumerate only the first one. Try appending
takeExactly(1000) on the result of zip. It might be even faster
than enumerate.
takeExactly didn't change the timings at all.
I did write a rough zip function that took advantage of random
access inputs and didn't need to account for different stopping
policies:
auto myZip(R1,R2) (R1 r1, R2 r2) {
struct MyZip(R1,R2) {
size_t index=0;
R1 rng1;
R2 rng2;
size_t length;
this (R1 r1, R2 r2) {
rng1=r1;
rng2=r2;
index=0;
length=r1.length;
}
auto empty() { return index==length; }
auto front() { return tuple(rng1[index],rng2[index]); }
void popFront() { index++; }
}
return MyZip!(R1,R2)(r1,r2);
}
This ended up being 40% faster than normal zip, both DMD 32/64.
I briefly tested with LDC and didn't notice any difference, which
I thought was weird, but didn't have time to investigate further.
That fact that zip is slower is not bad, as it provides far more
flexibility, different stopping policies, all types of ranges.
What is interesting (TBC) is the fact that it's only noticeably
slower using DMD.
Jordan
