DO NOT MERGE - Experimental Java Native Cached Write Batch #13115

not working yet - invalid link

comments there for what to pick up on

Extend original native write batch jmh tests to help us compare various write batch implementations. So-far-unused WriteBatchJavaCMem as placeholder for alternative implementation of native write batch.

- Finish making first prototype WriteBatchJavaNative work for put() - buffers put() requests on Java side - applies batched put() requests to C++ write_batch buffer on flush() - RocksDB.write(options, WriteBatchJavaNative) applies batch to DB - Clean up JMH performance tests for WriteBatchJavaNative vs existing WriteBatch

Give this prototype method UnsupportedOperationException on unimplemented methods so that we donm’t waste time investigating why jmh tests that call no-ops are so fast :-(

Pass contents in direct ByteBuffer (WriteBatchJavaNativeDirect) Refactor out from byte[] version (WriteBatchJavaNativeArray) Fix to pre-expand buffers by size rather than re-run insertion on overflow

“flushToDB” option used for stripping out the cost of the DB write at the end.

Refactor array/direct native variants into a single class with different static factories. Add native C++ support methods for creating the write batch on a write() if it doesn’t already exist. Add similar flush methods for creating the write batch on a flush() if it doesn’t already exist. Remove expansion on Java side - buffer is the requested size, behaviour should be to fill that and then flush, OR (TODO) to bypass it entirely (just make diret JNI calls to writebatch as before) for big writes

Refactored previously to remove subclass. So protected methods can now be private.

Bypass the java side buffer when put()sare bigger than 50% of the buffer size - which is controlled at constructor time. Doing a big Put() to this kind of write batch causes the buffer to be flushed (if there is anything in it) and then the Put() is performed directly over the JNI to C++ Note that the WriteBatch on the C++ side is created lazily; this may be on a flush of a batch (buffer is full), or it may be on the write of a batch to a DB, or it may be on a bypass write such as the one implemented here.

A quick step before trying to replicate the layout to the level at which it can be directly memory copied.

Pick up an efficient varint encoder from the interwebs Rewrite the encoding using that TODO - the C++ side, so all failing at present

Java-side write batch has same format as C++, so can be memcpy-ed (in theory). In practive it can be assign()-ed to an empty write batch in a single copy. In the case of an existing write batch, the std::string representation does not allow us to append() in 1-copy (because we have to copy into a std::string first to call append()) so we adapt what we did before, and step through the Java representation, calling Put() with Slices manufactured from the entries in the buffer. I think it is OK..

Last few changes to native write batch have modified the API slightly. Some of the test configuration is unnecessary or wrong, and the calls for creation are all part of a single class. Update these appropriately.

Translation of Varint32 I had stolen was bugged. Probably my translation is the problem. Use instead the slightly less efficient but more readable and adequately fast version. Fix the Varint32 test(s).

We should have added this optimization as part of the last set of changes. When we are calling write(), and the batch has not been created on the native/C++ side, we can use the same optimization as in flush, to wit: `WriteBatchInternal::SetContents(this, slice)` directly (via Append())

Update lists of files includes in builds and tests to correctly list the ones for the native write batch changes.

WriteBatchInternal::AppendContents allows us to append extra batch entries in bulk in a single copy, without the complexity of iteration and individual elements. Hope for improved performance.

WriteBatchInternal::AppendContents is not noticeable better performing, but it is cleaner and we have saved ourselves some code.

build an allocator into the write batch so that it can recycle bytebuffers rather than continually re-allocating them. When passing a direct bytebuffer, slice() it first before passing over JNI. This has a huge performance win, there is something (probing, or god forbid, copying) going on when we get the buffer from JNI. We still need to byte arrays, which are by far the slowest.

Second instance of - When passing a direct bytebuffer, slice() it first before passing over JNI Use critical section instead of env->GetByteArrayElements to avoid a copy of a potentially very large array, only part of which we may need. It has drawbacks, but for demonstrating performance and working round the byte[] version’s performance bug, it is invaluable.

1 operation now consists of writing a single batch of the required size. Performance is how many batches are written per second.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DO NOT MERGE - Experimental Java Native Cached Write Batch #13115

DO NOT MERGE - Experimental Java Native Cached Write Batch #13115

Commits on Nov 15, 2024