This avoids the following allocations over repeated use:
- A ``CharsetEncoder``
- A byte array to contain the contents of the string
- A wrapper, via ``ByteBuffer#wrap``, for the previously mentioned byte
array
This also removes a copy of the temporary byte array. This extra copy
is needed because ``String#getBytes`` returns a byte array and its
length must match the exact size of the contents.
This implementation requires that the builder retain a ``ByteBuffer``
and ``CharEncoder``. This is considered slower only for users that
will only allocate a single string in their buffers or none at all.
The improvement is especially potent if the builder is constantly reused
by its caller. This also eliminates the penalty for users that do not
use strings at all since the cost of allocating these fields is
now amortized.
The only allocation left in this code is a ``CharBuffer`` wrapper. It's
possible to eliminate this allocation using an additional copy but need
further profiling to see which is the bigger problem.
Removes the following allocations:
- ``CharsetDecoder`` is reused between calls
- ``CharBuffer#wrap`` removed in favor of heap
based char buffer that is reused
- Temporary ``char[]``, an intermediate copy inside ``StringCoding``
- Another ``char[]``, this is needed because ``StringCoding`` uses
a ``CharBuffer`` internally but returns a ``char[]``. Extra
characters need to be trimmed so this means yet another allocation
- Yet another ``char[]`` directly from ``__string`` for non-heap
based buffers
Removes the following copies
- No copy is performed to trim the allocation since a ``CharBuffer``
is used directly
- For non-heap based byte buffers, removes the copy that was
previously done in the __string function
This does need to get the TLS entry which implies at least some
contention on the thread object table and a fence.
Adding an API reference for the supported languages.
General docs cleanup, including a new `tutorial` section that
supports all of the supported languages.
Added samples for each supported language to mirror the new
tutorial page.
Cleaned up all the links by making them `@ref` style links,
instead of referencing the names of the generated `.html` files.
Removed all generated files that were unnecessarily committed.
Also fixed the C# tests (two were failing due to a missing file).
Bug: b/25801305
Tested: Tested all samples on Ubuntu, Mac, and Android. Docs were
generated using doxygen and viewed on Chrome.
Change-Id: I2acaba6e332a15ae2deff5f26a4a25da7bd2c954
Also checks for nesting of objects in vector construction.
This avoids common errors in FlatBuffer construction.
Change-Id: I5507c5d767684e20e94883a92448f05acefba4d6
Tested: on Linux.
Allows adding an already encoded UTF-8 string directly without
having to convert to a ``String`` first.
Change-Id: I23f9c738eec18fd35f4c14f58dbd0f6cf0970dc7
The satellite data of the ``ByteBuffer`` cannot be modified in
any way and stay thread safe in the presence of concurrent readers.
This implementation is simple and does introduce an allocation, however
without it multiple readers will quickly and continuously encounter
``IndexOutOfBoundsException`` exceptions.
An alternative, but possibly more controversial, implementation would
be to use ``Unsafe``. Using ``Unsafe``, it's possible to do an
array copy with a provided buffer index.
Change-Id: I851d4034e753b3be2931ee2249ec2c82dde43135
optimization would cause vtable fields from previous tables to be written.
Bug: 19046968
Change-Id: I781f7bcbceeaec0b499d4f1e4e5e8a1e750e0707
Tested: on Linux.
https://github.com/google/protobuf/blob/master/java/pom.xml
This isn't good enough to publish to Maven Central but will at
least allow users to publish to their local maven repository
using 'mvn install'
Change-Id: I91ea146cf7c5263fcf5d9823f70bb1ef0158f9a6
Tested: 'mvn install' runs succesfully and produces a .jar
Also cleaned up ByteBuffer usage in general: ByteBuffer.position
now universally indicates the start of a ByteBuffer.
Change-Id: Ic4bfb98f9df9501b8fc82de2c45db7d7311135ac
Tested: on Linux.
Readonly ByteBuffers and Direct ByteBuffers don't have a backing
array, and thus can't be used for writing FlatBuffers (though
they are fine for reading).
Change-Id: I4d7b9cc222b96161d0f8e92f34588bd3e0e38034
Tested: on Linux.
Also fixed flatc not outputting these identifiers for files
compiled on the command-line.
Bug: 16983987
Change-Id: I8b714cfea3a8e144fa52133f62b2f7eda6eb044a
Tested: on Linux
pjulien