Reputation: 1983
Let's say that we have common Serial and we are listening incoming bytes. Let's say that writing speed is more than reading and in order not to loose bytes from the Serial we introduce buffer and do the next. Serial listener just puts bytes in buffer (buffer writer thread) and buffer reader to extract bytes from buffer (buffer reading thread) and analyze data.
How efficient is using java 1.5 ConcurrentLinkedQueue<Integer>
taking into account boxing and unboxing while switching between primitive int incomingByte
from serial and Queue<Integer>
?
Restrictions:
I know that often fixed size buffer like int[] buffer[BUFFER_SIZE]
is used, but i'd like not to have buffer limit restrictions.
It's better to have thread-safety out of box and do not synchronize threads manually using blocking buffer or smth.
Upvotes: 1
Views: 622
Reputation: 533670
What is the transfer speed in byte/second of your device? If its less than 1 MB per second it probably doesn't matter which approach you take.
If you are writing bytes, why not use a ConcurrentLinkedQueue<Byte>
Every possible Byte value is cached so there is only a notional cost for auto-boxing and unboxing.
The main performance bottle neck is the linked entries in the queue. Every byte still creates an object (which is the node in the list) and each object uses around 16 bytes. In other words you can make your byte[]
16x larger and it will use the same amount of memory and create less garbage.
To meet your requirements, you could use ConcurrentLinkedQueue<Byte>
, however creating a ring buffer for a byte[]
will be faster (and easy to make re-sizeable)
If you are sending more that 10 MB/s I would suggest writing ByteBuffer and exchanging with another thread (i.e. so you are transfering large blocks at a time)
Upvotes: 1