[Debtags-devel] Hello, and a few improved tag descriptions

Mike Paul mike@wyzardry.net
Sun, 05 Jun 2005 16:33:29 -0400

Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2005-06-05 at 20:47 +0200, Benjamin Mesing wrote:
> > Probably premature optimization; I don't think constructing a std::set
> > is a particularly expensive operation, and maintainability of the sourc=
> > code is more important.  Consider this snippet from debtags.cc:
> I am not sure I agree here. Though generally I prefer writing readable
> code, the consume operations are called very often which makes each
> overhead accumulate. But I am not sure about the overall impact here.
> Some measurements should help, but who has time for this kind off
> stuff...?

That's true if the non-OpSet versions of the functions are called
frequently.  But it might be possible to avoid that by constructing the
OpSet once, "up-front", and passing it to the OpSet versions of the
functions; that way you avoid constructing it over and over again.
Basically, you'd never work with individual items; anytime you get an
individual item as input, you immediately construct an OpSet from it.

Or, do it the other way around:  have the single-item version of a
function be the "real" one, and the OpSet version is a forwarding
function which calls the single-item version in a loop.

I'm interested in doing some benchmarks to see if there's a performance
impact with the forwarding functions.  Right now I'm just trying to get
libtagcoll1 to compile from SVN though -- it's running into problems
trying to compile a PIC version of libtagexpr, saying there's no rule to
make "Tagexpr_pic.o", and I'm not familiar enough with the autotools (I
use SCons with my own code) to be able to easily track down where that
rule is supposed to be defined.
Mike Paul <mike@wyzardry.net>

Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Version: GnuPG v1.4.1 (GNU/Linux)