Hi Tim, Thanks, this is very useful. I'm not certain that this is the cause of the problem, as in my case the memory doesn't ever seem to be freed up, which suggests to me that there's actually a memory leak, rather than just high memory usage. However, this does help to pinpoint a possible source of the problem. I'll try uninstalling trac-bzr and see if the problem goes away. It would be unfortunate if this is necessary, as I find the RSS feed from the revision log to be one of the most useful features of using trac and bzr together...
thanks, Alex On May 21, 11:49 pm, Tim Black <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
