question

[publicocean0]

is there a way for saving the index to disk or different storage ?

if all the suffix tree is too much big is there a way for loading a part dinamically?

[npgall]

I'm afraid there's not a way to save or page in/page out the tree to disk in a way that it can be accessed. (You can serialize the tree, but this won't help with reducing runtime memory)

Have you tried using a CharSequenceNodeFactory with the suffix tree? This is the best way to reduce runtime memory overhead for the suffix tree.

Sent from my Android

On 17 Oct 2017 21:45, "publicocean0" [email protected] wrote:

is there a way for saving the index to disk or different storage ?

if all the suffix tree is too much big is there a way for loading a part dinamically?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/npgall/concurrent-trees/issues/28, or mute the thread https://github.com/notifications/unsubscribe-auth/ACuJioT7M6xYQOmRFXKQqU_pYfQxsFEnks5stRHygaJpZM4P8y5P .

[publicocean0]

ideally i had thought to visit the tree in inorder way. and save it. The tree is saved in way that every subtree is saved in a unique block. every block is in format sizeof block and data in recursive way. I consider the tree in memory is too much big so i cant load all,but every node contains a pointer to file position . when a subtree is not loaded in the search , you can load the partial subtree with a direct access to file. The part always in memory contains the first levels of the tree.

[publicocean0]

it was a good idea if the tree is not modifiable .... essentially you are right there no way to create a storage version fastly updatable in any sub-part ... the just way is key-value form removing any peristence advantage for trees.