Received-SPF: pass (google.com: domain of daniel@schoepe.org designates
	10.14.45.80 as permitted sender) client-ip=10.14.45.80; 
From: Daniel Schoepe <daniel@schoepe.org>
To: Justus Winter <4winter@informatik.uni-hamburg.de>,
	Philippe LeCavalier <support@plecavalier.com>, notmuch@notmuchmail.org
Subject: Re: nomuch_addresses.py
In-Reply-To: <20120221091509.8534.59492@thinkbox.jade-hamburg.de>
References: <87r4xur3rv.fsf@plc.plecavalier.com>
	<87fweamenf.fsf@schoepe.localhost>
	<20120221091509.8534.59492@thinkbox.jade-hamburg.de>
User-Agent: Notmuch/0.11.1+210~ge886eec (http://notmuchmail.org)
	Emacs/24.0.93.1 (x86_64-pc-linux-gnu)
Date: Tue, 21 Feb 2012 14:53:06 +0100
Message-ID: <87zkccjnst.fsf@schoepe.localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 21 Feb 2012 09:15:09 -0000, Justus Winter <4winter@informatik.uni-h=
amburg.de> wrote:
> Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]:
> >Just for completeness: I'm using the nice nottoomuch-addresses.pl script
> >[1] by Tomi Ollila *which doesn't require any bindings* and is incredibly
> >fast (after generating an initial address database).
>=20
> I don't get it. The perl script isn't using any library bindings,
> mainly because there are no libnotmuch bindings for perl. *But* it
> does call the notmuch binary which is worse:

I think that emphasis you added may be a bit misleading:

I specifically mentioned that it doesn't need bindings, because the
initial problem in this thread had to do with missing bindings, not
because I think it's inherently a good thing.

The reason I mentioned nottoomuch-addresses at all, is that completion
itself is _a lot_ faster (at least for me), compared to
addrlookup. According to the wiki, notmuch-addresses.py is even slower
than addrlookup, so I thought (and still think) that it was worth
mentioning. Of course, one could rewrite the database-generation part in
python using the bindings, but I personally don't think it's that
necessary.

> * incredibly high overhead (fork&exec) compared to a simple function
>   call (plus maybe some kind of ffi)

I think nottoomuch-addresses.sh is a good example how such performance
considerations can be outweighed by choosing a good "algorithm" instead
(extracting all addresses beforehand).

> * manual and error prone serialization of ''function arguments''
> * manual and error prone deserialization of ''return values''
> * very limited error reporting and handling capabilities
> * any kind of resource (think handle to a xapian database) is lost if
>   the process exists resulting in further overhead if the binary is
>   called multiple times
>=20
> I do get the feeling that it is perceived as desirable not to require
> any kind of notmuch bindings (David once said something similar about
> nmbug).

While I don't think that using bindings is a bad thing, the fact that we
can do non-trivial things like nmbug without them, seems to be a good
indicator for the quality of the command line interface though. (And
hence notmuch lends itself well to being used in shell scripts).

Cheers,
Daniel


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPQ6HCAAoJEIaTAtce+Z+JD5IQAIw+UtQfNS8MRx52YTgirM01
X7WBznp2k8r9J5n/ii2ZrE9/nkfwc2MGWJ9F7sbdijGvwUy+M2vFHgUSow6xRmud
nVkIs7XBH/YLG927BloiM3QRmgJuwoqJLJyPWniS4Xc2q0D1QUXDVeSwzLwHD9uL
SqW3q2gLbo5ZmV716n3YUnEzYl4+cyEv5bod91qYQM8fm4mFo5JcJ4EajjP3Rz5Y
2OFf5Ou8iK9fJGQXeVXtvYtd0tpMoD7WXS56zbJ8fbRdGTABiGORxQc0VGZob2Si
hJ0+/sss7BjYbUZgN3HSjlENVtCGuEZD4ioL8J0IKgYKr+vWs7lzSwp8aNK/Gm4Q
Fukco/H10wrMvhGv9YqXz+mn4lLFYWlO1HzYRicwPjueu46sNDmPU/cMefUIDonf
DKzxhGOGQgTpBIuIn9+VDuNHBU0mWehq8hcrHb1byFeRW817UB5ouK3r5paRqY/1
/XueSd7CD9gfi6bV01r2jQ8zxnOmisHVWjZq3DsyN7g8skpJtpybILLfQUIlhqHi
yuZJLkn2m47tY5dnmDyBeN22PiuNy22PuLUEQfM/w2NaxFxWUgI5W8VxtiKRgSCz
hQyvFJhliFebDs/AybOKTfG0tCWBdve9NTAtSv4rT2H9nnNzC71xl4ae39IOB91e
vZBT/7aJ9FRxlolFi8L8
=3Cc/
-----END PGP SIGNATURE-----
--=-=-=--