gecko-dev/python
Andrew Halberstadt 529aad2e2c Bug 1430825 - [mozlint] Split work up by paths instead of by linters, r=standard8
The initial motivation for this patch, was to prevent command lines that are
too long on Windows. To that end, there is a cap to the number of paths that
can be run per job. For now that cap is set to 50. This will allow for an
average path length of 160 characters, which should be sufficient with room to
spare.

But another big benefit of this patch is that we are running more things in
parallel. Previously, mozlint ran each linter in its own subprocess, but that's
it. If running eslint is 90% of the work, it'll still only get a single
process. This means we are wasting cores as soon as the other linters are
finished.

This patch chunks the number of specified paths such that there will be N*L
jobs where 'N' is the number of cores and 'L' is the number of linters.  This
means even when there's a dominant linter, we'll be making better use of our
resources. This isn't perfect of course, as some paths might contain a small
number of files, and some will contain a very large number of files.  But it's
a start

A limitation to this approach is that if there are fewer paths specified than
there are cores, we won't schedule enough jobs per linter to use those extra
cores. One idea might be to expand specified directories and individually list
all the paths under the directory. But this has some hairy edge cases that
would be tough to catch. Doing this in a non-hacky way would also require a
medium scale refactor.

So I propose further parallelization efforts be destined for follow-ups.

MozReview-Commit-ID: JRRu13AFaii

--HG--
extra : rebase_source : 242fb71fe0af8bd2a981bd10a7216bb897fe00ac
2018-01-16 16:01:20 -05:00
..
devtools/migrate-l10n Bug 1346025 - Move vendored python modules from /python to /third_party/python, r=ted 2017-05-25 11:48:03 -04:00
l10n/fluent_migrations Bug 1411012 - Migrate a small chunk of Privacy pane in Preferences to Fluent. r=mshal,Pike 2017-11-09 12:11:32 -08:00
mach Bug 1415614 - Add an API to log all structured messages; r=mshal 2017-11-09 15:09:52 -08:00
mozboot Bug 1433036 - OpenBSD bootstrap: node-devel package doesn't exist. r=froydnj,gaston 2018-01-25 07:05:22 +00:00
mozbuild Bug 1432223 - Add an --all-crates option to mach cargo check, to check all the crates. r=froydnj 2018-01-22 12:46:29 -05:00
mozlint Bug 1430825 - [mozlint] Split work up by paths instead of by linters, r=standard8 2018-01-16 16:01:20 -05:00
mozterm Backed out 5 changesets (bug 1421799) for failing firefox ui functional tests. r=backout on a CLOSED TREE 2018-01-03 20:21:28 +02:00
mozversioncontrol Bug 1405588 - [mozversioncontrol] Use base_ref instead of upstream as default outgoing comparison on git, r=gps 2017-11-01 12:57:03 -04:00
README Bug 1346025 - Move vendored python modules from /python to /third_party/python, r=ted 2017-05-25 11:48:03 -04:00
mach_commands.py Bug 1403012 - Fix TypeError when running python unittests via |mach test|, r=gbrown 2018-01-12 11:22:58 -05:00
moz.build Backed out 2 changesets (bug 1403519) for bustage on \python\mozbuild\mozbuild\test\frontend\test_reader.py on a CLOSED TREE 2018-01-17 07:23:40 +02:00

README

This directory contains common Python code.

The basic rule is that if Python code is cross-module (that's "module" in the
Mozilla meaning - as in "module ownership") and is MPL-compatible, it should
go here.

What should not go here:

* Vendored python modules (use third_party/python instead)
* Python that is not MPL-compatible (see other-licenses/)
* Python that has good reason to remain close to its "owning" (Mozilla)
  module (e.g. it is only being consumed from there).

Historical information can be found at
https://bugzilla.mozilla.org/show_bug.cgi?id=775243
https://bugzilla.mozilla.org/show_bug.cgi?id=1346025