Hi Simone: Thanks for jumping in with your thoughts.
On Mon, Feb 19, 2018 at 12:19 PM, Simone Bordet <simone.bor...@gmail.com> wrote: > Hi, > > Well, not so fast. > There are a lot of assumptions in the above code. > The first is that the ByteBuffer has a backing array, which may not be the > case. > If you write the right code that takes care of the possibility that > the ByteBuffer does not have a backing array, you end up with another > copy and more code. > More importantly, the implementation would have done all the copies > for you in order to feed your code with a final ByteBuffer. > So you are not really skipping the copies and the performance is not > different from below, where the possible copies are explicit. > Fortunately the Oracle JVM implements a backing array and the code I put out is exactly from my implementation and has been working superbly for the last year. Obviously, the day is approaching when I have to run on openJDK and I don't know if there is a backing array there since it is optional per the docs. > > DONE! More complicated, messy and very slow. (i.e. lots of wasted cpu > cycles) > > Nah :) > > ByteBufferInputStream bbis = new ByteBufferInputStream(); > for each partial ByteBuffer received by the listener { > bbis.add(byteBuffer); > } > ois = new ObjectInputStream(bbis); > MyDTO = ois.readObject(); > > Now, ByteBufferInputStream is not present in the JDK, and if you want > to complain you are in good (and conspicuous) company, as the JDK > engineers appear to avoid the issue since years now (e.g. create a > String from a ByteBuffer without copy). > Having said that, the class is trivial to implement (a naive version I > wrote is about 30 lines) and may even be provided as a utility class > by the JDK WebSocket implementers. > > The advantage is that ByteBufferInputStream can be written in a way > that performs *zero* copies, thanks to the JDK 9 WebSocket APIs - > add() would need to return a CompletableFuture. > If you don't want to confront with CompletableFutures, it can be > written in a way that performs just one copy. > Now we're talking strategy.....go man!! > > To sum up: > * with JDK 9 you need a utility class that you did not need with JDK 8 > * with JDK 9 you can actually perform a zero copy provided you put a > bit of effort (or the JDK guys do) > * with JDK 9 the number of byte copies is the same or better > > All in all, anything you can do with the JDK 8 API can be done in JDK 9. > For some cases, JDK 9 is more efficient than JDK 8. > For all other cases it's on par. > JDK 9 requires a utility class to convert from ByteBuffer to InputStream. > You can do it but being the lazy creature I am I want it done for me....now they're going to make me do it myself...... > > Note also that your requirement is to use blocking, stream-based, > byte[]-based APIs. > If you had chosen a data format for which a non-blocking parser based > on ByteBuffer APIs existed, you would be so happy about the JDK 9 > APIs. > Like what for instance? I'm looking for suggestions/strategies how best to adapt to the future. It's very unlikely I'm going to convert all my data to text before sending across the wire. > > I have a different experience, where clients may not be able to keep > up with the network. > This happens with browsers receiving a message and having to update a > gazillion DOM nodes (with all the ripple effects that this entails), > with clients generating so much garbage that the GC is heavily > interfering with their throughput, with proxy applications that have > different speeds on the 2 sides they proxy, and so on. > > You have my sincerest sympathy. <opinion> I feel sorry for anybody who has to interface with that pathetic pile of garbage we refer to as a browser and it's even more pathetic protocol. </opinion> You'd think our industry could do better. > Here I am seriously advocating to the net-dev JDK group to provide an > efficient solution, or at least start a discussion where appropriate, > for ByteBuffer to [Input|Output]Stream that is sorely missing in the > JDK. > > Thanks ! > Can we start a "Me too" movement? 😊 P. S. If you don't know about our silly American "Me too" movement consider yourself lucky! > >