Results 1 to 2 of 2

Thread: Strange Behaviour of Commit

  1. #1
    Junior Member
    Join Date
    Mar 2014

    Default Strange Behaviour of Commit

    In order to push STSdb to its limits I inserted all my data into a two dimension array (int[][]) in memory so that at the end I apply a set of InsertOrIgnore calls to ITable<int, int[]> and have the best performance and memory management of STSdb. Since it's a bulk insert without any look-up it is fast and performs well.

    The saved db is now 48 MB.

    The strange behavior happens when I open the db file to query it with some data (no insert at all). After performing look-ups if I call Commit on the engine then the size of database file will increase to 68 MB and won't decrease anymore ....!!!

    It's while If I insert the data one by one using InsertOrIgnore from scratch and Commt it at the end, and open it multiple times for look-up, the db size remain fixed.


  2. #2


    Read with commit and without commit can increase the database size. This is because querying for some key in W-tree may cause pouring down of group of records from some node to its children, in order to properly find the record for the key (on internal level the keys in W-tree can be duplicated - they are operations that are accumulating and annihilating each other). The modified nodes by the pouring down process may expire from cache and have to be stored.

    A first full table forward + commit (after sequences of inserts) also causes pouring down of all table records from the internal W-tree nodes to the leaf nodes. This causes storing of the modified leaf nodes to new places in the heap (and increases speed of all future readings).

    The database size increases and decreases depending on the writing-reading-committing patterns. The back-end file is truncated as much as possible after each successful commit.

    For more conservative data size policy you can try different space allocation strategy in the heap. The default heap has two strategies:
        /// <summary>
        /// Strategies for free space allocation.
        /// </summary>
        public enum AllocationStrategy : byte
            /// <summary>
            /// Searches for free space from the current block forwards (default behaviour).
            /// </summary>
            /// <summary>
            /// Always searches for free space from the beginning (reduces the space, but may affect the read/write speed).
            /// </summary>
    In some cases they can have practically similar behavior, in other - may differ substantially. You can change the Heap allocation strategy at any time:
            Heap heap = (Heap)engine.Heap;
            heap.Strategy = AllocationStrategy.FromTheBeginning;
    Last edited by a.todorov; 23.04.2014 at 17:30.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
2002 - 2014 STS Soft SC. All Rights reserved.
STSdb, Waterfall Tree and WTree are registered trademarks of STS Soft SC.