Running multiple commands on commandserver interface

[Ton Plomp]

I'm using LabVIEW wich doesn't have a native pipe interface, that's done
via a DLL interface to win32.
So the time i'm getting is probably most overhead in calling the DLL.
The time I get 38 msec per 'version' command scales linear up to 1000 calls.

I'll see if I can get the overhead of the dll call.

Ton

2012/4/12 Matt Mackall <mpm at selenic.com>

> On Thu, 2012-04-12 at 19:50 +0300, Idan Kamara wrote:
> > On Thu, Apr 12, 2012 at 6:55 PM, Matt Mackall <mpm at selenic.com> wrote:
> >
> > > On Thu, 2012-04-12 at 17:33 +0200, Ton Plomp wrote:
> > > > Yes Idan,
> > > >
> > > > removing the null byte on the client side did fix the issue!
> > > >
> > > > For timing info I ran 100 hg version, versus 100 times version on
> the hg
> > > > commandserver:
> > > > Pipe: 4,1 seconds
> > > > CLI: 15 seconds
> > >
> > > Hmm, that's a lot slower than I would have hoped. It runs about 10x
> > > faster here (100 loops .5 seconds with python-hglib), but it seems to
> > > still be doing a bunch of unnecessary work on each call.
> >
> >
> > Did you call rawcommand or version on the repo object? Because the latter
> > is cached.
> >
> > This is what I'm getting:
> >
> > $ python -m timeit -n 1000 -s 'import hglib; r = hglib.open()' -c
> > 'r.rawcommand(["version"])'
> > 1000 loops, best of 3: 30 usec per loop
>
> 30 usec is suspiciously short. I got:
>
> 1000 loops, best of 3: 0 usec per loop
>
> ..which rather strongly suggests that something's confusing timeit here.
>
> A loop of 100 calls to rawcommand takes ~.5 seconds here.
>
> > But version is probably not the best candidate for a benchmark.
>
> It's actually a great candidate because it does so little work: almost
> all the time is the overhead we're trying to measure. Granted, some of
> that overhead is not overhead for "real" commands.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120413/e7f8b00a/attachment-0002.html>