[Gnu-arch-users] Re: arch performance with large trees

[Catalin Marinas]

Miika Komu <address@hidden> writes:
> Our project (*) uses tla for storing a complete, modified linux kernel.
> tla 1.2 is far too slow for e.g. commits and listing changes with the
> configuration we use. Just yesterday I did a commit that finished in 15
> minutes even with revision libraries (greedy+sparse).

What machine are you using? Do you work over NFS?

I also use arch for storing the Linux kernel and I'm quite happy with
it. It is, indeed, better to hard-link to the revision library. I
noticed that it gets slow with time so I re-create the tree with
"tla get --link" from time to time.

See the messages below for some figures:

http://article.gmane.org/gmane.comp.version-control.arch.user/30691
http://article.gmane.org/gmane.comp.version-control.arch.user/30716

Also make sure that you really use a revision library, otherwise the
pristine trees generation is quite slow.

> We prefer to build inside the source tree which can explain at least part
> of the slowness, but we're not giving up on this building method.

This shouldn't affect too much (maybe worse figures for tree-lint).

> Do you know any neat tricks to make the commits faster? I've heard that
> hard linking directly to the revlib could make this faster, but how much
> faster (does anyone have any figures)?

hard-linking made a visible improvement for me. You could also try
with a newer tla and see if it makes any difference.

> Is tla-2.0 going to have any performance optimizations with large
> trees?

The current tla has an inodes list but I don't think it is used with
NFS directories (it is incredibly slow without that list since it
needs to diff every file).

For minor modifications you can use "tla commit -- file1 file2 ..."

Catalin