Trie memory limit

[ezorita]

Update MT planner to alternate query and construct and tree removal steps. This way only a subset of trees will be held in memory simultaneously allowing to set a max memory.

This will potentially reduce the parallel scaling efficiency due to the increased number of MT jobs.

[ezorita]

The upper bound of the trie size is:

num_seqs*seq_length/n_tries * sizeof(node_t) //bytes

hence, the lower bound for n_tries is:

min_n_tries = num_seqs*seq_length*sizeof(node_t)/MAX_MEMORY

but at the lower bound for n_tries the build jobs are not parallelized because only one trie can be built at the same time. Hence, a good choice may be:

n_tries = n_threads*min_n_tries

and then schedule the jobs with the following order:

BUILD PHASE
build(0), build(1), build(2) ... build(n_threads-1)
SEQUENTIAL QUERY AND FREE
all query(0) then free(trie(0)) and schedule build(n_threads)
all query(1) then free(trie(1)) and schedule build(n_threads+1)
...
all query(n_threads) then free(trie(n_threads)) and schedule build(2*n_threads)

and so on.

[ezorita]

Also, it'd be advantageous to make a priority scheduler, where build jobs have higher priority than query jobs, mainly because they are much longer and block the subsequent query jobs.