You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a couple of things we can do in BarrageUtils.java to reduce the allocation behavior when unmarshalling Object types. Today we need an intermediate byte[] array taken from a ByteBuffer, that we pass to constructors of variable-sized objects, like String, BigInteger and BigDecimal.
By having access to the BigDecimal(byte[] arr, int offset, int len) ctor available since Java 9, we can have better resizing behavior for the work array we use today (code currently used in the String case, but not in the BigDecimal/BigInteger cases). For this we need gwt support, not yet there, so when a version of gwt with this ctor is available, we can upgrade our dependency and try this.
Also, colin described an strategy where we can pry our way directly to the ByteBuffer without having to use an intermediate byte[] object taking advantage of some JS specific methods. As described by Colin over slack message: "we can actually grab the underlying typedarray inside the ByteBuffer (see the TypedArrayHelper that was used to make the LE ByteBuffer to begin with) and cast that to byte[]"
The text was updated successfully, but these errors were encountered:
There are a couple of things we can do in BarrageUtils.java to reduce the allocation behavior when unmarshalling Object types. Today we need an intermediate byte[] array taken from a ByteBuffer, that we pass to constructors of variable-sized objects, like String, BigInteger and BigDecimal.
By having access to the
BigDecimal(byte[] arr, int offset, int len)
ctor available since Java 9, we can have better resizing behavior for the work array we use today (code currently used in the String case, but not in the BigDecimal/BigInteger cases). For this we need gwt support, not yet there, so when a version of gwt with this ctor is available, we can upgrade our dependency and try this.Also, colin described an strategy where we can pry our way directly to the ByteBuffer without having to use an intermediate byte[] object taking advantage of some JS specific methods. As described by Colin over slack message: "we can actually grab the underlying typedarray inside the ByteBuffer (see the TypedArrayHelper that was used to make the LE ByteBuffer to begin with) and cast that to byte[]"
The text was updated successfully, but these errors were encountered: