← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to notes/performance.txt

  • Committer: mbp at sourcefrog
  • Date: 2005-03-28 02:24:18 UTC
  • Revision ID: mbp@sourcefrog.net-20050328022418-9d37f56361aa18e9
doc: more on ignore patterns

Show diffs side-by-side

added added

removed removed

Lines of Context:
notes/performance.txt
269
269
 2969 files changed, 372168 insertions(+), 153284 deletions(-)
270
270
 
271
271
I wonder why it is not exactly the same?  Maybe because the python
272
 
diff algorithm is a bit differnt to GNU diff.
273
 
 
274
 
----
275
 
 
276
 
2005-03-29  
277
 
 
278
 
full check, retrieving all file texts once for the 2.4 kernel branch
279
 
takes 10m elapsed, 1m cpu time.  lots of random IO and seeking.
280
 
 
281
 
----
282
 
 
283
 
 
284
 
mbp@hope% time python =bzr deleted --show-ids 
285
 
README                                             README-fa1d8447b4fd0140-adbf4342752f0fc3
286
 
python =bzr deleted --show-ids  1.55s user 0.09s system 96% cpu 1.701 total
287
 
mbp@hope% time python -O =bzr deleted --show-ids 
288
 
README                                             README-fa1d8447b4fd0140-adbf4342752f0fc3
289
 
python -O =bzr deleted --show-ids  1.47s user 0.10s system 101% cpu 1.547 total
290
 
mbp@hope% time python -O =bzr deleted --show-ids
291
 
README                                             README-fa1d8447b4fd0140-adbf4342752f0fc3
292
 
python -O =bzr deleted --show-ids  1.49s user 0.07s system 99% cpu 1.565 total
293
 
mbp@hope% time python =bzr deleted --show-ids   
294
 
README                                             README-fa1d8447b4fd0140-adbf4342752f0fc3
295
 
python =bzr deleted --show-ids  1.55s user 0.08s system 99% cpu 1.637 total
296
 
 
297
 
small but significant improvement from Python -O
298
 
 
299
 
----
300
 
 
301
 
Loading a large inventory through cElementTree is pretty quick; only
302
 
about 0.117s.  By contrast reading the inventory into our data
303
 
structure takes about 0.7s.  
304
 
 
305
 
So I think the problem must be in converting everything to
306
 
InventoryEntries and back again every time.
307
 
 
308
 
Thought about that way it seems pretty inefficient: why create all
309
 
those objects when most of them aren't called on most invocations?
310
 
Instead perhaps the Inventory object should hold the ElementTree and
311
 
pull things out of it only as necessary?  We can even have an index
312
 
pointing into the ElementTree by id, path, etc.
313
 
 
314
 
 
315
 
as of r148
316
 
 
317
 
bzr deleted  1.46s user 0.08s system 98% cpu 1.561 total
318
 
 
319
 
 
320
 
Alternatively maybe keep an id2path and path2id cache?  Keeping it
321
 
coherent may be hard...
 
272
diff algorithm is a bit differnt to GNU diff.
 
 
b'\\ No newline at end of file'