200-600x slower Dlang performance with nested foreach loop
methonash
nope at dne.net
Sun Jan 31 16:50:15 UTC 2021
On Sunday, 31 January 2021 at 00:53:05 UTC, Steven Schveighoffer
wrote:
> I'd suggest trying it in reverse. If you have the sequence
> "cba", "ba", "a", then determining "a" is in "ba" is probably
> cheaper than determining "a" is in "cba".
I have user requirements that this application track string IDs
that get collapsed under parents. To minimize/simplify array
concatenations, I figured that going in descending order might
make those operations less expensive.
Though I think this is also worth trying.
> Are you still convinced that it's possible to do it in under 2
> seconds? That would seem a huge discrepancy. If not, what
> specifically are you looking for in terms of performance?
Good question. As a sanity check, at some point this past week, I
re-wrote everything in a single contained Perl program, and
running that program on the dataset I've shared above took well
over 2 hours of wall time.
Considering that the index() function in Perl is pre-compiled, I
imagine that Dlang running 4-5x faster is a pretty good speed
boost, as it may only be benefiting from the speed of compiled
loops over interpreted loops.
What confuses me, at this point, is this: I originally wrote the
D code using foreach in this style:
foreach( i, ref parentString; strings )
{
foreach( j, ref childString; strings[ i + 1 .. $ ] )
{
// ...
}
}
Essentially, the value of j printed to stdout should always be
larger than the value of i. Yet, when running in the above style,
the values of j reported to stdout inevitably become smaller than
i, suggesting that the loop is somehow traversing backwards. How
can this be explained?
More information about the Digitalmars-d-learn
mailing list