Remove byte array allocation from JNI string methods #564
Conversation
Getting string data out of SQLite has involved 2 copies: 1 in JNI-land (allocating a byte buffer to return to Java) and 1 in Java-land (creating a String instance). Rather than do the first copy we can return a direct ByteBuffer instance and then do the conversion from byte -> String in Java as before. So this removes a copy getting string data out of SQLite and into Java. Since these arrays are immediately copied into Java string instances accessing SQLite memory in Java will be safe. I added a test for a string that used non-ASCII codepoints just to make sure this was still working as expected.
|
Fixes #561 (well, it's much better than existing behavior, at least). |
| @@ -154,4 +156,18 @@ public void testCloseStatement() | |||
|
|
|||
| assertTrue(resultSet.isClosed()); | |||
| } | |||
|
|
|||
| @Test | |||
| public void testReturnsNonAsciiCodepoints() | |||
There was a problem hiding this comment.
My changes here didn't break anything, I just noticed there wasn't a test for this.
|
Thanks for the quick fix! The code basically looks good to me. I'll double-check whether we need to properly release the allocated memory in sqlite. |
|
Nice, I was working off the guidance here https://sqlite.org/c3ref/column_blob.html which seems to indicate it would handle it until |
|
@tildedave Thanks. Yeah. In this usage, allocated DirectByteBuffer will be immediately converted into Strings, so it should be safe. |
|
be care for, nativeByteBuffer to string is a slow operation due to the decoder access each byte by JNI |
Getting string data out of SQLite has involved 2 copies: 1 in JNI-land
(allocating a byte buffer to return to Java) and 1 in Java-land (creating a
String instance).
Rather than do the first copy we can return a direct ByteBuffer instance and
then do the conversion from byte -> String in Java as before. So this removes
a copy getting string data out of SQLite and into Java.
Since these arrays are immediately copied into Java string instances accessing
SQLite memory in Java will be safe. I added a test for a string that used
non-ASCII codepoints just to make sure this was still working as expected.