[Pkg-bazaar-commits] ./bzr/unstable r89: - don't flush the debug log file so often

[mbp at sourcefrog.net]

------------------------------------------------------------
revno: 89
committer: mbp at sourcefrog.net
timestamp: Fri 2005-03-25 14:24:47 +1100
message:
  - don't flush the debug log file so often
modified:
  bzrlib/trace.py
  notes/performance.txt
-------------- next part --------------
=== modified file 'bzrlib/trace.py'
--- a/bzrlib/trace.py	2005-03-23 03:09:50 +0000
+++ b/bzrlib/trace.py	2005-03-25 03:24:47 +0000
@@ -45,12 +45,12 @@
     b = 'bzr: warning: ' + msg + '\n'
     sys.stderr.write(b)
     _tracefile.write(b)
-    _tracefile.flush()
+    #_tracefile.flush()
 
 def mutter(msg):
     _tracefile.write(msg)
     _tracefile.write('\n')
-    _tracefile.flush()
+    # _tracefile.flush()
     if verbose:
         sys.stderr.write('- ' + msg + '\n')
 
@@ -60,13 +60,13 @@
     if not silent:
         sys.stderr.write(b)
     _tracefile.write(b)
-    _tracefile.flush()
+    # _tracefile.flush()
 
 
 def log_error(msg):
     sys.stderr.write(msg)
     _tracefile.write(msg)
-    _tracefile.flush()
+    # _tracefile.flush()
 
 
 

=== modified file 'notes/performance.txt'
--- a/notes/performance.txt	2005-03-09 06:49:00 +0000
+++ b/notes/performance.txt	2005-03-25 03:24:47 +0000
@@ -185,4 +185,37 @@
 
 The real fix is perhaps to use some kind of weave, not so much for
 storage efficiency as for fast annotation and therefore possible
-annotation-based merge.
\ No newline at end of file
+annotation-based merge.
+
+-----
+
+
+2005-03-25
+
+Now we have recursive add, add is much faster.  Adding all of the
+linux 2.4.19 kernel tree takes only 
+
+finished, 5.460u/0.610s cpu, 0.010u/0.000s cum, 6.710 elapsed
+
+
+However, the store code currently flushes to disk after every write,
+which is probably excessive.  So a commit takes
+
+finished, 8.740u/3.950s cpu, 0.010u/0.000s cum, 156.420 elapsed
+
+
+Status is now also quite fast, depsite that it still has to read all
+the working copies:
+
+mbp at hope% bzr status                                                            ~/work/linux-2.4.19
+bzr status  5.51s user 0.79s system 99% cpu 6.337 total
+
+strace shows much of this is in write(2), probably because of
+logging.  With more buffering on that file, removing all the explicit
+flushes, that is reduced to 
+
+mbp at hope% time bzr status  
+bzr status  5.23s user 0.42s system 97% cpu 5.780 total
+
+which is mostly opening, stating and reading files, as it should be.
+Still a few too many stat calls.
\ No newline at end of file