I found a strange call to `drop()` in `ByteString1.writeToBuffer(ByteBuffer)`. `drop()` instantiates a new `ByteString1` which is immediately discarded to GC. Appears unnecessary.
Removing it makes the `ByteString1` implementation match the one `ByteString1C`.
* Use Charset instead of charset name
When using the reference to the charset directly, j.l.StringCoding will
run without doing a charset by name lookup.
* Use Charset instead of charset name
Add a method taking charset instance for every method with charset name.
* Use Charset instead of charset name
Rolled back change of parameter name as that would not be fully API compatible.
Otherwise, with 2.12,
ByteString().toString == "ByteString.ByteString1C()"
which would expose implementation details in the string representation.
This can lead to failing tests due to test expecting a particular string
representation of a ByteString which might be bad practice, yes, but is also
convenient.
The change is due to a fix in Scala for SI-9019 for which the string representation
of TraversableLike was changed which ByteString inherits.
See https://github.com/scala/scala/pull/5258/files
* =act clean up ByteString#drop(...)
Current implementation has a good algorithm but seems a little bit complicated.
Clening-up does not suffer the performance (actually seems to have the better
performance when dropping(N-1)) where N is the length, and is easy to understand
almost the same algorithm now.
* Change private[akka] to priavte
* Rename go(...) and some variables
They should be easy for us to understand what they are.
* Add benchmark of ByteString#drop(...)
Currently, we use ByteStringBuilder to create a new ByteString instance,
which would not be quite efficient.
Instead of doing this, we can do as follows so that we can achieve better performance:
1. Seek the index of _last_ vector element we need to _take_
2. Find the number of characters left to take from the _last_ ByteString1 element.
3. Create ByteString based on the information we obtained from 1 and 2
Then we just need to create a new Vector[ByteString1] at most twice, which should be
better than the current implementation, i.e., _append_ a new element every time we check
bytestrings(Vector[ByteString1]) element, which ends up O(N) _append_ execution where _N_ is
the length of bytestrings.
- heavily inspired by spray.io.Pipeline
- fully functional style: a stage returns the resulting commands and
events, which makes it impossible to mess with the pipeline from the
inside
- object allocations are optimized away for emtpy and 1-elem results
- added type-safety, verifying that stages match up
- management commands “from the side” for configuration or async events
- full Java API and docs
