optimize put by reuse memory of kvData before

[kingeasternsun]

optimize the put

[kingeasternsun]

good advise

[holiman]

I thought some more about this. I think it violates the API. There are some methods in the memdb, e.g. Find, and Get, which returns the value slice from the kvData buffer.

They are documented with The caller should not modify the contents of the returned slice, implying that the returned value has not been copied, but is a direct reference to the backing data.

With this PR, a data-race is introduced, since the readlock is only held during the Get/Find, but not afterwards.

• Routine 1: Get(aaa) -> returns 'bbb'
• Routine 2: Put(aaa, cc) -> overwrites 'bbb' with cc.

And now, when Routine 1 looks at the data, it sees bbc. Hence why the kvData needs to remain append-only, and cannot be modified in-place.

[holiman]

About that scenario ^ it would be good with a testcase for that.

Put(aaa, bbb)
val = Get(aaa)
Put(aaa, cc)
assert( val == bbb)

It should hold true for both disk-db and memdb

[holiman]

It might be that this actually already works, since leveldb uses sequence numbers overlaid on memdb. So this change does make memdb api unsafe, but it won't matter when the memdb is used through a regular db -- it won't Put the exact key another time, but only a key with the same ukey prefix.

Which still is a bit dangerous, because it's a very subtle bug which will be hard to find. However, due to this usage of sequence numbers, I think the optimization is probably moot aswell.

[kingeasternsun]

moot aswe

very great thoughts