Feature/persistent storage improvements

[benedekh]

Note: not tested yet

[benedekh]

Tested.

Some measurements with 200 key-value pairs. Key was just a number as a String (0-199), and value was a "valalalala " string. Number after the colon is the elapsed time in seconds (stroage as SSD, if it is in square brackets then the storage was HDD). Not a too precise benchmark just a 1st round estimate.

• put 200: 0.698 [0.777]
• get 200: 0.323 [0.311](with initialization: collecting persisted keys from the files)
• remove 200: 0.414 [0.448](with initialization: collecting persisted keys from the files)
• put & get 200: 0.882 [0.974]
• put & remove 200: 1.002 [1.045]
• get & remove 200: 0.616 [0.666](with initialization: collecting persisted keys from the files)

How storage algorithm works now?

It stores the entries in a map, the key and the value are separated. Each map has a max. capacity, and each map is persisted into a file. If a map has free capacity then the allocation algorithm first uses that map to put a new key-value pair into that. If there is no free map, then a new map is created for the key-value pair to be stored.

[benedekh]

The PR is closed, because in the meantime the storage functionality has been developped further in PR #82 on a different branch. The changes suggested in the code review are included in the new branch.