On Thu, May 12, 2011 at 02:39:34PM +0200, Pierre THIERRY wrote: > Scribit W. Trevor King dies 12/05/2011 hora 06:59: > > I ran the tests on a tmpfs partition on the same computer instead. > > [...] The results were suprisingly similar to the other direct-access > > runs. > > Actually, I don't find it so surprising. I mean, you could hope to > reduce the constant factor, but as long as don't change the way the bugs > are accessed, with N bugs, you will still have O(N) time for listing.
True, but I had been expecting the slowdown to be due to file access, and the lack of change on tmpfs suggests it is due to file parsing and the rest of the listing algorithm. There is potentially lots of room for improvement in the parsing (I've pushed a few patches to my tree). > 1) make merging of indexes possible 2) reduce the load needed to create > the indexes > > As far as 2) is concerned, I was thinking about something like storing > the index in the VCS as some kind of parallel branch, This makes me nervous ;). How do you find the index-branch commit that corresponds to a given bug-repository commit? And for people (like us at BE) that keep the bug repo in the same branch as the code, would you have a separate index-branch tracking each bug-repo branch? > but having the need to rebuild the index when you first clone a > repository may not be that bad (and it could be automatic, BE could > trigger the building in the background, the first time it's called). I like this better (it's how .be/id-cache works already). On the other hand, it does not accelerate `be diff` and others that look at previous commits, and I'm not sure how you would use it with a remote BE repository, for example: be --repo http://bugs.bugseverywhere.org/ list except by generating an index ".be/index-<bugdir>:<revision>", and assuming that nothing important changed during a single revision. > As for 1), I see at least two ways: either the format makes it possible > for the VCS to do the merge itself, or BE inspects the relevant commits > from the VCS and does the merging. The problem here is that BE is not involved in VCS-initiated merges. Unless you set something up with Git's hooks to run a pre-commit index regeneration, BE will never be called. If your VCS doesn't have an appropriate hook, you'll be calling BE by hand to regenerate the index during every merge. Yuck. > And maybe, if building the index is fast enough and it's not disruptive > when run in the background, we could skip all that complexity and just > rebuild it from scratch each time it would be complex to do otherwise... Building the index will be equivalent to a single `be list` run with the current setup, so it shouldn't be too slow. This is what we do now, except we take the "too complex to do otherwise" route all the time ;). -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
pgpwOjHps2gPk.pgp
Description: PGP signature
_______________________________________________ Be-devel mailing list [email protected] http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
