If I recall correctly this is a known issue in bzr itself--I've lost my notes gathered from a number of bug comments out there, but my recollection is that in order to provide a diff between two revisions, trac-bzr requests the full content of each revision then does its own diff in memory. This is resource-intensive. See this bug: https://bugs.launchpad.net/trac-bzr/+bug/57447.
Aha...I found my notes on this issue and appended them below; hope they help! Tim Black I wasn't doing any upload at the time. I've researched the issue some and think the memory usage is due to the way the trac-bzr plugin handles diffs & changesets on directories--it recreates a full copy of each revision's directory path then diffs those two copies. The reason for this is stated in trac-bzr's HACKING file: ------------------ trac wants the revision log of a dir to include what happens to its contents. bzr only notices changes to the dir itself (renames and moves of the dir, not its contents). ------------------ I think this is related to several other performance bottlenecks mentioned in trac-bzr HACKING: ------------------ Performance =========== Constructing a BzrDirNode is slow because it walks its children to determine the right "most recent" revision. Because it is pretty common to iterate over the children afterwards and we need to determine their most recent revision anyway we cache those values (BzrDirNode.revcache). Speeds up the source browser in a directory with a couple of subdirs. BzrDirNode.get_history is a bit slow and pretty memory-hungry. Again the need to manually pick up changes to children is the root cause. It has to construct full inventories and/or deltas between revisions to pick up changes to children, while for the other node types we just have to open the "versionedfile" for that particular file. ------------------ and in trac-bzr's README: ------------------ Speed issues ------------ Some user-level operations are rather slow, because Trac's assumptions about which repository operations are cheap vs expensive doesn't match Bazaar's design. In particular, Bzr doesn't track "which revision last modified files in this directory." In theory, this can be solved by caching the results of expensive operations. ------------------ I have a hunch this performance bottleneck is related to bzr's inability to log directory paths. From 'bzr help log': ------------------ Note: If the path is a directory, only revisions that directly changed that directory object are currently shown. This is considered a bug. (Support for filtering against multiple files and for files within a directory is under development.) ------------------ I installed the revnocache plugin, and do not think it provided any speed improvement. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
