I am trying out new operations on cdt list with Aerospike server 3.7.3. I am trying out single element append operation on an existing list of length varying from 50K to 1M. What I am observing is that list append time is not constant, but increases with increase in length of the list i.e. computational complexity of O(n). As per cdt list documentation present over here, append time is given as O(1) i.e. constant. My data model is all in memory without any reference to hdd. Is this expected behavior?
The table only records the complexity of the element walk, and for append, it is O(1).
However, the overall transaction time can also be affected by memcpy, due to the copy-on-write design. This time is usually negligible, but for operations that have fast element-walk time (such as append()), its effect will be noticeable, and is likely what you are seeing. We will enhance the document to make this clearer.
How are you measuring and what are your numbers?
I am taking time measurement by calling “gettimeofday” before and after the append operation. My setup is simple. First I create a record with list bin (all are int64) of a large size (ranging from 50k to 2M). After that single element append operation is performed and time is measured for this append operation. Following is my observation -
- for append into list of size 50k - 0.16 ms
- for append into list of size 100k - 0.25 ms
- for append into list of size 500k - 1 ms
- for append into list of size 1M - 4 ms
- for append into list of size 2M - 8 ms
Hi Jin_dev, As there is a max limit of 1M per record, how did you managed to store 2M
- for append into list of size 2M - 8 ms
Thanks, Dhanasekaran
I believe these limits are applicable only when you use SSD (block storage) for data. I am storing all the data in-memory, so I don’t think there any such limit.