Reading the NSA’s codebaseLemonGraph review–Part IV–Compressed, sortable integers
time to read 2 min | 244 words

Before going over the actual query implementation, I wanted to talk about something that I just realized. I said previously that I don’t understand why LemonGraph is using its integer encoding method, because it is less efficient than using variant sized integer. What I didn’t take into account is that the method LemonGraph is using gives short, but sortable, integers.

Here is the encoding method:

image

Now, let’s see what kind of binary output this will generate when given a few numbers:

image

The key here is that the number of bytes is stored as the first item. This means that when we compare two numbers using memcmp(), the number with more bytes is considered greater. This is indeed the case, because if you need more bytes to store a number, it is obviously larger.

What about two numbers that have the same number of bytes? This is handled by simple binary comparison of the values. If they are the same size, the fact that the encode() output them in big endian format means that we can compare them using memcmp() and be done with it.

This is a really nice way to both keep the values sorted and to avoid storing the full 8 bytes for numbers that are usually much smaller.

Tweet Share Share 0 comments
Tags:

More posts in "Reading the NSA’s codebase" series:

  1. (13 Aug 2018) LemonGraph review–Part VII–Summary
  2. (10 Aug 2018) LemonGraph review–Part VI–Executing queries
  3. (09 Aug 2018) LemonGraph review–Part V–Query parsing
  4. (08 Aug 2018) LemonGraph review–Part IV–Compressed, sortable integers
  5. (07 Aug 2018) LemonGraph review–Part III - Figuring out queries
  6. (06 Aug 2018) LemonGraph review–Part II - Storing edges and properties
  7. (03 Aug 2018) LemonGraph review–Part I - Storing Nodes