RAM usage: find a way to memory map the English lexicon

[joanise]

g2p is used on the ReadAlong Studio back-end server, and causes a fairly high amount of RAM to get used.

• importing networkx (any subpart of it, even just the top-level import) costs about 30MB (see RAM usage: replace networkx elements used by the web API server #394)
• importing the languages database costs about 60MB, 40 or 50 of which is likely the English lexicon

This is more complex than replacing networkx algorithms: if we could find a way to memory map the English lexicon from disk, instead of loading in into RAM, that would let us realize a significant memory saving on the API server, for both the g2p backend and the RAS web-api back-end.

[dhdaines]

Ah, I see that I commented on #400 that the representation used there could very easily be memory mapped.

So... this might be pretty easy. I'll take a look.

[dhdaines]

So... in order for memory mapping the representation to make sense we fundamentally need to do two things:

1. Pack it into a single block of memory (as bytes, not str)
2. Put this block of data in a separate file (presumably, one file for each mapping that uses alignments, though there's only one at the moment) referenced from langs.json.gz

What makes this difficult is that the current implementation relies on being able to call bisect_left on (blocks of) alignment entries which is definitely not going to work with a packed memory representation, unless we unpack it into a list, which defeats the whole point of doing this. So we have to:

1. Store the indices of entries in the blob of data separately (we don't want to scan the blob to reconstruct them since this will just result in the whole file being paged into memory, defeating the purpose of using mmap!)
2. Implement our own binary search (fine, that isn't hard to do)

At this point I'm pretty sure we don't need to do the "double bisection" algorithm anymore and can just search over the individual alignments.

The question then becomes, if we store these indices in the JSON, do we actually save any memory? Probably? We can of course also put them in the binary blob.

[dhdaines]

On further reflection implementing our own binary search isn't necessary (though it might be desirable). The entry indices mentioned above can be wrapped in a class (should be a NamedTuple probably) which implements __lt__ (or whichever ordering is used by bisection) such that it looks at the binary blob to do comparisons.