Merge lp:~jameinel/bzr/2.0.6-peak-commit-mem into lp:bzr/2.0
| Status: | Merged |
|---|---|
| Approved by: | bzr PQM on 2010-04-29 |
| Approved revision: | not available |
| Merged at revision: | not available |
| Proposed branch: | lp:~jameinel/bzr/2.0.6-peak-commit-mem |
| Merge into: | lp:bzr/2.0 |
| Diff against target: |
53 lines (+9/-5) 2 files modified
NEWS (+7/-3) bzrlib/groupcompress.py (+2/-2) |
| To merge this branch: | bzr merge lp:~jameinel/bzr/2.0.6-peak-commit-mem |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Robert Collins (community) | 2010-04-19 | Approve on 2010-04-19 | |
|
Review via email:
|
|||
Commit Message
Reduce peak memory usage by 1 compressed text copy when compressing in 2a foramts.
Description of the Change
I'm proposing this for 2.0 (and thus by extension for 2.1 and trunk). I chose 2.0 because it really is a rather trivial change that has a nice positive impact on peak memory when working with large files.
It is related to bug #566940, but this is really only 1 step out of many.
To test this, I created an 80mb file filled with incompressible data, and did 'bzr commit'. I also expanded the data with 'hexlify', which makes it 160mb, but should compress 2:1.
With the 80mb dataset, peak memory went from:
349MB => 267MB (82MB, aka 1 copy)
With the 160mb dataset, the peak memory went from:
465MB => 371MB (94MB, ~1 compressed size)
As near as I can tell, it is the removal of self._z_content which is saved. We still hold the fulltext in memory, because FulltextContent
Still, saving 1 copy of compressed content for a 1 line change is worthwhile.
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Collins wrote:
> The proposal to merge lp:~jameinel/bzr/2.0.6-peak-commit-mem into lp:bzr/2.0 has been updated.
>
> Status: Approved => Queued
> Queue Position: (not set) => 73
So this was marked as Queued to be merged into lp:bzr/2.0, but as of
today, I don't see it actually merged, and I don't see an error or
success message for this.
I'm going to just submit it myself, but I figured I'd make a comment to
figure out what was going on.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkv
gdIAmQFGlycq4UT
=s3Au
-----END PGP SIGNATURE-----
| Robert Collins (lifeless) wrote : | # |
you can see it in the queue at http://
yesterday for one of the causes of pqm not completing properly wasn't
deployed till this morning; there is also
https:/
to change the status on a failing merge, with the result it stays in the
queue. I'm considering changing the order to work around that (though in
general I think its better to not silently bounce things out of queued
state. You can manually remove things from queued just by visiting the merge
proposal and clicking on the edit to change from queued to approved.
| Vincent Ladeuil (vila) wrote : | # |
Status set to Approved instead of Queued as pqm is not able to process it (or rather
it's so happy to process it that it handles it again and again, see bug #567333 for a similar
case).
| bzr PQM (bzr-pqm) wrote : | # |
Successful steps
Failure output:
All lines of log output:
Executing star-merge lp:~jameinel/bzr/2.0.6-peak-commit-mem at Thu Apr 29 04:25:59 2010
['Nothing to merge.']

Looks great to me.