Re: [Gnu-arch-users] tla library-add - high cpu

[Tom Lord]

    > From: Andrew Suffield <address@hidden>

    > On Fri, Sep 05, 2003 at 08:40:15AM +1000, Robert Collins wrote:
    > >         tla library-add seems to spend most of it's time thinking, not 
patching
    > > or retrieving.=20

    > > For instance, in a recent tla library-add
    > > address@hidden/squid--HEAD--3.0 (~400 patches), into a
    > > clean revision library, tla took ~15 seconds to get back to the start
    > > and do the first patch. After that though, it spends quite some time
    > > doing nothing obvious, and top shows tla at 100% cpu.

    > > The archive was being accessed via sftp. It's possibly a retrieval code
    > > problem - or a logic problem of some sort. It's spending 30-40 seconds
    > > per patch, and those patches can be grabbed by sftp in about 2 seconds,
    > > so I suspect a bad O somewhere in tla itself.

    > I believe it's actually a wait-for-ack problem - library-add
    > repeatedly fires off a request, and sits waiting for a response,
    > instead of pipelining. So latency kills you.


Nope -- at least not if this is the problem we fixed on IRC the other
night.

Rob is running on a 64-bit machine.  Patching is a fairly
regexp-intensive operation (due to computing inventories -- those
=tagging-method regexps).  The default DFA and NFA cache sizes of Rx
is measured in bytes -- but allocated in multiples of the machine's
word-size.  So, in effect, the cache size was cut in half on a 64 bit
machine.  Word has it that just bumping the cache size fixed the
problem.

(It's not impossible I've got the context wrong in the cross traffic
between IRC and the list, of course.)

-t