Optimize knownProducts for direct-to-JAR compilation #939
Conversation
retronym
force-pushed
the
faster/classes-in-jar
branch
from
609618f to
46d2659
Compare
| def knownProductsPar = | ||
| if (AnalysisCallback.parallelKnownProducts) new ParVector(knownProducts) else knownProducts |
There was a problem hiding this comment.
Does this use the default fork/join scheduler? If so, could it end up competing against other tasks or potentially other Zinc compilation that are also trying to do the same thing? Or it finishes quickly enough that it won't surface? (But takes long enough time if it's not parallelized?)
There was a problem hiding this comment.
Looks like I added the parallel thing in 94ba81e, but I'd be happy to see it gone if it's not working.
There was a problem hiding this comment.
In this case I think the best idea is to keep it sequential. If this is a bottle neck, we can try to first reduce the overhead in sequential code (like I've done here, but I'm sure there are more opportunities.) Sequential code is a bit easier to profile and tune. Using parallelism should be done with a careful understanding of whether the task size suitable for parallel collections (e.g. something like (1 to 1000).par.count(_ % 2 == 0) is slower than the sequential version.
I've added a commit to remove the ParVector altogether.
retronym
force-pushed
the
faster/classes-in-jar
branch
from
f0b62bd to
f00ef7d
Compare
Fixes #933