* Benjamin Drung <benjamin.dr...@profitbricks.com> [140203 13:15]:
> Okay. Attached the patch for my prototype. Be aware: It's just a
> prototype that is just able to run the commands that I wanted to test,
> but isn't near to be ready for mainlining. The prototype implements case
> 2 just because that was my initial idea, but now I tend to think that
> case 1 might be easier/cleaner.
Thanks. I'll take a look this weekend.
> > It sounds quite slow either way. Perhaps the way to go is instead
> > changing the data format, like having the version first (perhaps even in
> > preparsed format to speed things up).
>
> Good idea, but is this function really time critical? It should be only
> called when comparing duplicate keys (which shouldn't happen that often,
> does it?).
It might also happen when updating some value otherwise. (And if the
version is in some meta-data first one also does not have to
differentiate between binaries and sources that much). One could also
take the opportunity of a format change to allow for other possible
future meta data (like the first added timestamp).
> How do you want to preparse the version?
if versions are compared they are split into epoch version and revision
and version and revision are gain split into sequences of numbers and
not-numbers. Dpkg for example first parsed all the functions and later
only compares the already split part. if easily possible it could make
sense to store it in a format like that (but then parsing a on-disk
format of the split data might be just as time-consuming as just looking
at the real data).
> How would the data format change? Currently the database value contains
> just the control junk. We could put the pair (version, control) as value
> into the database. How should the pair separated? Maybe with a null
> character?
something like that.
> Then we could just use the pointer to the value as version
> string (the null character from the pair separation would also be used
> to terminate the string).
Yes. That would be the "store verbatim" and non-preparsed variant.
Alternatively one could first store a length of the string, so one can
even faster jump to the control part.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
