The formula for percentage change in _any_ metric, without exception, is:
(new_value - old_value) / old_value
Some people flip the sign of their result, presumably because they
associate "positive" with "good" or want to render a graph where
"upward" bars are "good". Making this mistake consistently leads to
tremendous confusion.
This is particularly horrible when people confuse time and speed,
which are inverse metrics. Flipping the sign in order to present the
inverse metric is commonly done, but is mathematically incorrect and
is often extremely misleading. That's why it's so important to use a
standard (mathematically correct) convention for reporting a change in
percentage of any metric.
So, if I triple the size of the code, I'll now see +200%, not -200% which is
mathematically impossible and shear nonsense.
Added title column.
Make short parameter consistent.
Made output option -c work.
Fixed csv output for -l flag.
Shortened too long lines.
Fix linting errors.
Remove comment.
* E101: indentation contains mixed spaces and tabs
* E111: indentation is not a multiple of four
* E128: continuation line under-indented for visual indent
* E302: expected 2 blank lines, found 1
* W191: indentation contains tabs
The repo contains roughly 80 Python scripts. "snake_case" naming is used for
local variables in all those scripts. This is the form recommended by the PEP 8
naming recommendations (Python Software Foundation) and typically associated
with idiomatic Python code.
However, in nine of the 80 scripts there were at least one instance of
"camelCase" naming prior to this commit.
This commit improves consistency in the Python code base by making sure that
these nine remaining files follow the variable naming convention used for
Python code in the project.
References:
* PEP 8: https://www.python.org/dev/peps/pep-0008/
* pep8-naming: https://pypi.python.org/pypi/pep8-naming
Fixes:
* multiple statements on one line (colon) (E701)
* missing whitespace around arithmetic operator (E226)
* missing whitespace around operator (E225)
* closing bracket does not match visual indentation (E124)
* blank line contains whitespace (W293)
* continuation line missing indentation or outdented (E122)
* continuation line over-indented for hanging indent (E126)
* missing expected blank line (E301)
* trailing whitespace (W291)
* unexpected spaces around keyword / parameter equals (E251)
* whitespace after '(', '[' or '{' (E201)
* whitespace before ')', ']' or '}' (E202)
* whitespace before ',' or ':' (E203)
Fixes:
* Unused import
* Redundant backslash
* Use of discouraged if not x in y
* Use of deprecated form of raising exceptions
Follow-up to PR #655 as requested by @gribozavr
In Python 3, 'print' was changed from a statement to a function. Using
the __future__ module allows scripts to use print function whether
running with Python 2.6+ or Python 3.x. This commit changes as many
instances of print as I could find to use the print function and the
__future__ module.
Add unit tests to cmpcodesize. As a basic starting point for unit
tests, add some tests for edge cases in listFunctionSizes.
Users may now run the unit tests for cmpcodesize by running
`python utils/cmpcodesize/setup.py test`.
By adding a setup.py file, users may install cmpcodesize to their PATH,
by running `python utils/cmpcodesize/setup.py install`.
Should the Swift project choose to do so, this package may also be uploaded
to the Python Package Index (https://pypi.python.org/pypi). Doing so would
allow anyone with an Internet connection to install cmpcodesize by
running `pip install cmpcodesize`.
Setuptools also provides a convenient way to run unit tests (yet to be
added as of this commit).
Split up cmpcodesize script into a package, with a main.py file that
acts as an entry point to the program. The functions that use otool to
actually determine binary size have been moved into compare.py.
Note that to execute cmpcodesize, you may now run either:
1. `utils/cmpcodesize/cmpcodesize.py`
2. `python utils/cmpcodesize/cmpcodesize/main.py`
The cmpcodesize script is a little unwieldy--the same file contains
command-line argument parsing, otool invocation, and result
output formatting.
To split the script into several files, we'll need to turn it into a
Python package. In order to do so, we first move it into its own
directory.
Note that to invoke the script, you'll now need to run
`utils/cmpcodesize/cmpcodesize`. That additional path component is
inconvenient for now, but things will get better soon.
`$SWIFT_OLD_BUILDDIR` and `$SWIFT_NEW_BUILDDIR` are only necessary when
not using `--` to delineate two sets of files.
1. Only grab them from the environment when `--` is *not* used.
2. Assert if they're not present in that codepath. Print what *is*
specified in the environment, in order to help the user correct
their mistake.
We can detect improper use of --list very early in the script's
execution. Favor doing so to warn the user earlier. Also, add
documentation for proper use of --list.
The values are already stored on the parsed arguments, so remove the
variables and clear up the variable namespace a little.
Also, use snake_case, which is more Pythonic. This commit doesn't
change all variable names in the interest of keeping changes minimal.
We can detect improper combinations of --list and
--additional-sections/--category very soon when executing the script.
Assert in those cases. This used to be a warning.
Because of the way Python uses references for lists, the logic around
`oldFileArgs`, `newFileArgs`, and `curFiles` is difficult to follow.
Use a less efficient algorithm to find and split the elements based on
the '--' separator.
Although its performance is negligibly worse O(2n) as opposed to O(n), it's
easier to understand and uses one less imperative loop. Also, it's not as if
we'll ever encounter input that makes the performance difference
matter, so :shipit:!
Rather than manually parse the arguments passed to cmpcodesize, use the
Python stdlib. By doing so, we can eliminate a lot of redundant code.
One problem: argparse can't handle positional arguments of the string
'--', since it misinterprets them as optional arguments. We replace
that stirng with a special token.
