[MERGE/RFC] Add dotted-decimal revision numbers to merge_sorted output

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Thu, 2006-09-07 at 03:07 -0400, Aaron Bentley wrote:
>> Robert Collins wrote:
>>> However, at the real world level, log is not fast enough to be affected
>>> by this : log in a branch with 7K revisions is several orders of
>>> magnitude slower than 80ms.
>> No, when log is displaying a restricted range (e.g. -r -20..-1), it
>> takes ~60ms.  And it always emits a few log messages quickly, to fill
>> the screen.  So for log formatters that show merges, slowing down
>> merge_sorted could have an observable effect, because it increases the
>> time before the first few log messages are emitted.
>>
>> It probably makes sense to run the log benchmarks before and after.
> 
> Before:
> running tests...
> test_cmd_log               OK    71ms/36317ms
> test_cmd_log_subprocess    OK   374ms/24164ms
> test_log                   OK   599ms/24322ms
> test_log_screenful         OK    74ms/23863ms
> test_log_screenful_line    OK    48ms/24122ms
> test_log_screenful_short   OK    31ms/24679ms
> test_log_verbose           OK  1187ms/27523ms
> test_merge_log             OK   155ms/46109ms
> 
> ----------------------------------------------------------------------
> Ran 8 tests in 231.113s
> 
> After:
> running tests...
> test_cmd_log               OK    81ms/25084ms
> test_cmd_log_subprocess    OK   467ms/26084ms
> test_log                   OK   620ms/26893ms
> test_log_screenful         OK    84ms/27294ms
> test_log_screenful_line    OK    49ms/27448ms
> test_log_screenful_short   OK    34ms/26300ms
> test_log_verbose           OK  1208ms/28204ms
> test_merge_log             OK   160ms/48176ms
> 
> ----------------------------------------------------------------------
> Ran 8 tests in 235.497s
> 
> So slower, but not drastically so - I would say its within the margin
> for noise on our measurements tbh.

The ones I'm particularly looking at are test_log and
test_log_screenful.  Both are about 15% slower with the patch.  The
figures look accurate +/-3, because test_log_screenful_line and
test_log_screenful_short appear unaffected, and this makes sense because
they don't show merges, and so don't do a merge_sort.

They represent the cases of 'bzr log|less' and 'bzr log -r -4', so
they're pretty common cases, and the hit will be worse with more
revisions.  How does merge_sort scale with the number of revisions?

> So there is a performance hit. 70ms of real time, 10% of total execution
> time. Whats the verdict ? 

Well, even if merge_sort scales O(n), a hit of 100ms on 10,000 revisions
is probably tolerable.  But I'd really like to have a version of
merge_sort (and therefore, the new revnos) that scaled with the log
range, not the size of the graph-to-origin.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAMwr0F+nu1YWqI0RAuIJAJ9J47MfnMt3V3YxFHRQs9gCmxJ8wwCffWTK
mv6oEiakpuM/cuZowHZMgis=
=Art0
-----END PGP SIGNATURE-----