zeroconf having effects on commands besides serve and paths?

[Masklinn]

Recently, I started noticing performance issues with `hg log` (I don't
use hg as much as I used to these days so I have no idea when it
started): on very small repos (under 50 revisions), log would display
its output and then wait for a *long* time, seemingly doing nothing.
11s long:

    hg log  0.18s user 0.11s system 2% cpu 11.580 total
 

Now this seemed weird, hg is not supposed to be slow. I have a bunch
of extensions enabled so I used the HGRCPATH trick Augie posted in the
"Non-working Mercurial after Mac OS X Lion install" to check the
performances of an extensionless hg, and sure enough

    HGRCPATH=/dev/null hg log  0.06s user 0.03s system 96% cpu 0.101 total

Considering the first run shows almost no CPU time, I thought
something was going on with the network, and the only enabled
extension I figured could have an impact there was `zeroconf`[#].
Disabled than, and…

    hg log  0.14s user 0.05s system 94% cpu 0.206 total


(I also have `color` and other stuff enabled, so I'm it makes sense
that this run is slower than the second one)

Now here's the question: why does zeroconf have such a terrible impact
on the performances of `log`? the website states this:

    This extension allows hg serve to announce a repository via
    zeroconf/bonjour (and it should be able to do so on Mac,
    Linux and Windows). To browse repositories on your local 
    network, just use hg paths.

and the extention's own help states:

    Zeroconf-enabled repositories will be announced in a network
    without the need to configure a server or a service. They can be
    discovered without knowing their actual IP address.

it looks like it's supposed to affect `serve` and `paths`, and it
could probably hook into `clone` as well in order to clone a repo
by name, but why would it make `hg log` a hundredfold slower? Why
does it even do anything on `hg log`?

I looked a bit at the extension's code, but since I never looked
into that I have no idea what I'm checking. The function
`zeroconf.configitems` looks mighty suspicious though: it seems
to perform a complete zeroconf discovery any time the `paths`
section of the config is read.

Is it possible that `hg log` somehow looks up the local repository's
`paths` (maybe due to an other extension), and that this triggers
zeroconf's network discovery?

Standard extensions enabled, apart from zeroconf:
bisect, bookmarks, children, churn, color, convert, extdiff, gpg,
graphlog, hgk, mq, patchbomb, progress, purge, rebase, record,
transplant

This parties extensions enabled:
hgsubversion, histedit, hggit, hgshelve

[#] enabled it a long time ago, to do some ad-hoc sharing with a few
    friends, had never disabled it.