<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Nov 14, 2017 8:15 AM, "Julian Andres Klode" <<a href="mailto:jak@debian.org" target="_blank">jak@debian.org</a>> wrote:<br type="attribution"><blockquote class="m_-8410057555487648747quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-8410057555487648747elided-text">On Tue, Nov 14, 2017 at 03:35:02PM +0000, John Lenton wrote:<br>
> On 14 November 2017 at 12:34, Julian Andres Klode <<a href="mailto:jak@debian.org" target="_blank">jak@debian.org</a>> wrote:<br>
> > On Tue, Nov 14, 2017 at 01:00:54PM +0100, Zygmunt Krynicki wrote:<br>
> >> I would love if we have a compact representation of mapping from name<br>
> >> to list of bits of information where each bit can be a small structure<br>
> >> with some data. Apart from components for ubuntu archive it could be<br>
> >> used to store facts about snap packages, flatpaks, etc. I would try to<br>
> >> avoid a simplistic command -> package mapping as that will force us to<br>
> >> encode things into strings in an ad-hoc way.<br>
> ><br>
> > That makes sense to me. But then we're back on a db, I guess. I sort<br>
> > like this minimal approach.<br>
><br>
> I was thinking in the other direction, was going to see how it behaved<br>
> with sqlite as the store. Would that be objectionable?<br>
<br>
</div>Using a relational database for a simple key -> structure mapping seems<br>
overkill and a mismatch for the problem, and the SQL does not make it<br>
more readable.<br>
<br>
I'd play with lmdb and kyotocabinet, these are two high-performance<br>
key-value file databases and then encode a structure as mentioned<br>
before.<br></blockquote></div></div></div><div dir="auto">I had some kyotocabinet code, (i maintain that package, which btw is in mentors) but this way is at least half the size. (Kyotocabinet is 1mb and it almost doubles the size of the db, even using lower overhead b-tree back end. These entries are just very small.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-8410057555487648747quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the text file approach, we can even go human, readable, like git:<br>
<br>
git just encodes a number in a fixed-length decimal number, we can do<br>
the same, and then just encode (length, key), (length, data) pairs after<br>
each other (or as mentioned, just use the "index" as the field id, and<br>
store field ids in the progrma). Uses a bit more space, but encodes<br>
everything in a format you could read with a text editor, and should<br>
not be terribly less efficient.<br>
<br>
The thing is: This needs to be as efficient as possible: it should<br>
be below 100ms (or better 50ms), regardless of whether caches are dropped<br>
or not.<br>
<br>
                Python code     |       Shawn's code<br>
<br>
SSD, cache              50ms                    5ms<br>
SSD, " dropped         256ms                   15ms<br>
HDD, cache              50ms                    5ms<br>
HDD, " dropped         530ms                   15ms<br>
<br>
I guess Shawn's code could even be improved in performance by<br>
avoiding the subprocess execution, avoiding various ld cache<br>
lookups and library loads.<br></blockquote></div></div></div><div dir="auto">I am going to have to bring it in process to add the spell check code.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-8410057555487648747quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That said, space requirements might matter too.<br>
<div class="m_-8410057555487648747elided-text">--<br>
Debian Developer - <a href="http://deb.li/jak" rel="noreferrer" target="_blank">deb.li/jak</a> | <a href="http://jak-linux.org" rel="noreferrer" target="_blank">jak-linux.org</a> - free software dev<br>
Ubuntu Core Developer                              de, en speaker<br>
</div></blockquote></div><br></div></div></div>