Question

I abstracted out a sorted list that I need to keep in C. One way is best for reading and the other for writing.

WRITE: search KeyNumeric then KeyAlpha and write *Data

Key1 : [ KeyA, *Data1A, KeyB, *Data1B, KeyC, *Data1C ]
Key2 : [ KeyA, *Data2A, KeyB, *Data2B, KeyC, *Data2C ]
Key3 : [ KeyA, *Data3A, KeyB, *Data3B, KeyC, *Data3C ]


READ: search KeyAlpha then KeyNumeric and read *Data

KeyA : [ Key1, *Data1A, Key2, *Data2A, Key3, *Data3A ]
KeyB : [ Key1, *Data1B, Key2, *Data2B, Key3, *Data3B ]
KeyC : [ Key1, *Data1C, Key2, *Data2C, Key3, *Data3C ]

Does anyone recognize what would be the most efficient way to represent this data structure in memory?

Answer 1

If I understand correctly:

• your data has a composite key that consists of a number and some kind of alphabetic (you don’t say if it’s a character or a string).
• Sometimes you have the alpha-key, and need to search for the numeric, and sometimes vice-versa (it happens to be read and (over)write, but that’s beside the point, probably).
• Insert and delete are rare but need to be supported.

I’m also going to assume that the data keys are sparse, so a straight “[N][A]” array is not going to work for you.

Since you want the data to be double indexed, I’d suggest that you need some kind of linked structure: either a list or a tree.

To do it with linked lists, your C structure might look like this:

struct stuff {
  int num_key;
  char alpha_key;

  /* The number-first lists.  */
  struct {
    struct stuff *next_num;
    struct stuff *next_alpha;
  } num_list;

  /* The alpha-first links.  */
  struct {
    struct stuff *next_alpha;
    struct stuff *next_num;
  } alpha_list;

  struct data Data;
};

So, if you have data items 1A, 1B, 1C, 2A, 2B, 2C, 3A, 3B, 3C these links would work like this:

• 1A num_list.next_num points to 2A.
• 1A num_list.next_alpha points to 1B.
• 1A num_alpha.next_alpha points to 1B.
• 1A num_alpha.next_num points to 2A.
• 2B num_list.next_num is NULL.
• 2B num_list.next_alpha points to 2C.
• 2B num_alpha.next_alpha is NULL.
• 2B num_alpha.next_num points to 3B.

So, in words, num_list.next_num always points to something with the next number, but the first letter available. Similarly, alpha_list.next_alpha always points to something with the next letter, but the first number available. If you’re not looking at the head of the secondary list then pointer for the primary list is NULL because you never want to traverse the data that way, and maintaining a real pointer there would either cause bugs, or cause extra maintenance on insert or delete.

You can think of it as two lists of lists:

• num_list.next_num is a list of the heads of the num_list.next_alpha lists.
• aplha_list.next_alpha is a list of the heads of the alpha_list.next_num lists.

To find an item, you first move across one of the primary lists, num_list.next_num or aplha_list.next_alpha, and then down one of the secondary lists, num_list.next_alpha or num_alpha.next_num.

---

So, clearly there are some efficiency issues with this:

• malloc of all these little data blocks is inefficient.
• lists are O(n) to access.

If you are dealing with large quantities of data I would do two things:

1. Use some kind of balanced tree instead of flat lists. The ‘heads of the lists’ then becomes the ‘roots of the trees’.

2. Allocated a fixed-sized array of struct stuff and use array indexes as the links, instead of pointers. Then simply maintain a “free list” of unused slots. If your data out-grows the array then use realloc or allocate a second memory block and remember which indexes lie in which block.