You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IntArrays.parallelQuickSort() really sped up sorting terms while writing them to disk or while reconstructing the global terms list.
Sorting hits by a HitProperty seems to still be done single-threaded in the HitsInternal* classes. We should test if using parallelQuickSort() speeds this up. This method will fall back to regular quickSort() if there's fewer than 8192 elements, so should always be faster.
The only way it could actually end up being slower is if any locking occurs. For example, Collator.compare() is a synchronized method, so using that in a Comparator will slow down parallel sorts by a lot (confirmed using the TestSortPerformance utility). This could be counteracted by precalculating a value that can be compared without locking (a CollationKey in this example).
The text was updated successfully, but these errors were encountered:
IntArrays.parallelQuickSort()
really sped up sorting terms while writing them to disk or while reconstructing the global terms list.Sorting hits by a
HitProperty
seems to still be done single-threaded in theHitsInternal*
classes. We should test if usingparallelQuickSort()
speeds this up. This method will fall back to regularquickSort()
if there's fewer than 8192 elements, so should always be faster.The only way it could actually end up being slower is if any locking occurs. For example,
Collator.compare()
is a synchronized method, so using that in aComparator
will slow down parallel sorts by a lot (confirmed using theTestSortPerformance
utility). This could be counteracted by precalculating a value that can be compared without locking (aCollationKey
in this example).The text was updated successfully, but these errors were encountered: