[Speed] Testing a wide Unicode build of Python 2 on speed.python.org?

[Nick Coghlan]

speed.python.org has been updated to split out per-branch results for
easier cross version comparisons, but looking at the performance repo
suggests that the only 2.7 results currently reported are for the
default UCS2 builds.

That isn't the way Linux distros typically ship Python: we/they
specify the "--enable-unicode=ucs4" option when calling configure in
order to get correct Unicode handling.

Not that long ago, `pyenv` also switched to using wide builds for
`manylinux1` wheel compatibility, and conda has similarly used wide
builds from the start for ABI compatibility with system Python
runtimes.

That means the current Python 2 benchmark results may be
unrepresentative for anyone using a typical Linux build of CPython:
the pay-off in reduced memory use and reduced data copying from Python
3's dynamic string representation is higher relative to Python 2 wide
builds than it is relative to narrow builds, and we'd expect that to
affect at least the benchmarks that manipulate text data.

Perhaps it would make sense to benchmark two different variants of the
Python 2.7 branch, one with a wide build, and one with a narrow one?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia