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" ***@***.***> 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 <#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.