worker: change partition strategy to every Nth element
The only consumer of the worker pool code today is `hg update`.
Previously, the algorithm to partition work to each worker process
preserved input list ordering. We'd take the first N elements, then
the next N elements, etc. Measurements on mozilla-central demonstrate
this isn't an optimal partitioning strategy.
I added debug code to print when workers were exiting. When performing
a working copy update on a previously empty working copy of
mozilla-central, I noticed that process lifetimes were all over the
map. One worker would complete after 7s. Many would complete after
12s. And another worker would often take >16s. This behavior occurred
for many worker process counts and was more pronounced on some than
others.
What I suspect is happening is some workers end up with lots of
small files and others with large files. This is because the update
code passes in actions according to sorted filenames. And, directories
under tend to accumulate similar files. For example, test directories
often consist of many small test files and media directories contain
binary (often larger) media files.
This patch changes the partitioning algorithm to select every Nth
element from the input list. Each worker thus has a similar composition
of files to operate on.
The result of this change is that worker processes now all tend to exit
around the same time. The possibility of a long pole due to being
unlucky and receiving all the large files has been mitigated. Overall
execution time seems to drop, but not by a statistically significant
amount on mozilla-central. However, repositories with directories
containing many large files will likely show a drop.
There shouldn't be any regressions due to partial manifest decoding
because the update code already iterates the manifest to determine
what files to operate on, so the manifest should already be decoded.
#!/usr/bin/env bash
# A simple script for opening merge conflicts in the editor.
# Use the following Mercurial settings to enable it.
#
# [ui]
# merge = editmerge
#
# [merge-tools]
# editmerge.args=$output
# editmerge.check=changed
# editmerge.premerge=keep
FILE="$1"
getlines() {
grep -n "^<<<<<<" "$FILE" | cut -f1 -d:
}
# editor preference loosely based on https://mercurial-scm.org/wiki/editor
# hg showconfig is at the bottom though, since it's slow to run (0.15 seconds)
ED="$HGEDITOR"
if [ "$ED" = "" ] ; then
ED="$VISUAL"
fi
if [ "$ED" = "" ] ; then
ED="$EDITOR"
fi
if [ "$ED" = "" ] ; then
ED="$(hg showconfig ui.editor)"
fi
if [ "$ED" = "" ] ; then
echo "merge failed - unable to find editor"
exit 1
fi
if [ "$ED" = "emacs" ] || [ "$ED" = "nano" ] || [ "$ED" = "vim" ] ; then
FIRSTLINE="$(getlines | head -n 1)"
PREVIOUSLINE=""
# open the editor to the first conflict until there are no more
# or the user stops editing the file
while [ ! "$FIRSTLINE" = "" ] && [ ! "$FIRSTLINE" = "$PREVIOUSLINE" ] ; do
$ED "+$FIRSTLINE" "$FILE"
PREVIOUSLINE="$FIRSTLINE"
FIRSTLINE="$(getlines | head -n 1)"
done
else
$ED "$FILE"
fi
# get the line numbers of the remaining conflicts
CONFLICTS="$(getlines | sed ':a;N;$!ba;s/\n/, /g')"
if [ ! "$CONFLICTS" = "" ] ; then
echo "merge failed - resolve the conflicts (line $CONFLICTS) then use 'hg resolve --mark'"
exit 1
fi
exit 0