bundle2: implement generic part payload decoder
The previous commit extracted _payloadchunks() to a new derived class.
There was still a reference to this method in unbundlepart, making
unbundlepart unusable on its own.
This commit implements a generic version of a bundle2 part payload
decoder, without offset tracking. seekableunbundlepart._payloadchunks()
has been refactored to consume it, adding offset tracking like before.
We also implement unbundlepart._payloadchunks(), which is a thin
wrapper for it. Since we never instantiate unbundlepart directly,
this new method is not used. This will be changed in subsequent
commits.
The new implementation also inlines some simple code from unpackermixin
and adds some local variable to prevent extra function calls and
attribute lookups. `hg perfbundleread` on an uncompressed Firefox
bundle seems to show a minor win:
! bundle2 iterparts()
! wall 12.593258 comb 12.250000 user 8.870000 sys 3.380000 (best of 3)
! wall 10.891305 comb 10.820000 user 7.990000 sys 2.830000 (best of 3)
! bundle2 part seek()
! wall 13.173163 comb 11.100000 user 8.390000 sys 2.710000 (best of 3)
! wall 12.991478 comb 10.390000 user 7.720000 sys 2.670000 (best of 3)
! bundle2 part read(8k)
! wall 9.483612 comb 9.480000 user 8.420000 sys 1.060000 (best of 3)
! wall 8.599892 comb 8.580000 user 7.720000 sys 0.860000 (best of 3)
! bundle2 part read(16k)
! wall 9.159815 comb 9.150000 user 8.220000 sys 0.930000 (best of 3)
! wall 8.265361 comb 8.250000 user 7.360000 sys 0.890000 (best of 3)
! bundle2 part read(32k)
! wall 9.141308 comb 9.130000 user 8.220000 sys 0.910000 (best of 3)
! wall 8.290308 comb 8.280000 user 7.330000 sys 0.950000 (best of 3)
! bundle2 part read(128k)
! wall 8.880587 comb 8.850000 user 7.960000 sys 0.890000 (best of 3)
! wall 8.204900 comb 8.150000 user 7.210000 sys 0.940000 (best of 3)
Function call overhead in Python strikes again!
Of course, bundle2 decoding CPU overhead is likely small compared to
decompression and changegroup application. But every little bit helps.
Differential Revision: https://phab.mercurial-scm.org/D1387
WiX installer source files
==========================
The files in this folder are used by the thg-winbuild [1] package
building architecture to create a Mercurial MSI installer. These files
are versioned within the Mercurial source tree because the WXS files
must kept up to date with distribution changes within their branch. In
other words, the default branch WXS files are expected to diverge from
the stable branch WXS files. Storing them within the same repository is
the only sane way to keep the source tree and the installer in sync.
The MSI installer builder uses only the mercurial.ini file from the
contrib/win32 folder, the contents of which have been historically used
to create an InnoSetup based installer. The rest of the files there are
ignored.
The MSI packages built by thg-winbuild require elevated (admin)
privileges to be installed due to the installation of MSVC CRT libraries
under the C:\WINDOWS\WinSxS folder. Thus the InnoSetup installers may
still be useful to some users.
To build your own MSI packages, clone the thg-winbuild [1] repository
and follow the README.txt [2] instructions closely. There are fewer
prerequisites for a WiX [3] installer than an InnoSetup installer, but
they are more specific.
Direct questions or comments to Steve Borho <steve@borho.org>
[1] http://bitbucket.org/tortoisehg/thg-winbuild
[2] http://bitbucket.org/tortoisehg/thg-winbuild/src/tip/README.txt
[3] http://wix.sourceforge.net/