Производителност: ConcurrentLinkedQueue‹Integer› като сериен входящ буфер

Да кажем, че имаме общ сериен номер и слушаме входящи байтове. Да кажем, че скоростта на писане е повече от скоростта на четене и за да не губим байтове от серийния номер, въвеждаме буфер и правим следващото. Сериен слушател просто поставя байтове в буфер (нишка за запис на буфер) и четец на буфер, за да извлече байтове от буфер (нишка за четене на буфер) и да анализира данни.

Колко ефективно е използването на java 1.5 ConcurrentLinkedQueue<Integer>, като се вземе предвид боксирането и разопаковането при превключване между примитивни int incomingByte от серийни и Queue<Integer>?

Ограничения:

  1. няма ограничения за размера на буфера

Знам, че често се използва буфер с фиксиран размер като int[] buffer[BUFFER_SIZE], но бих искал да нямам ограничения за ограничаване на буфера.

  1. безопасен за нишка

По-добре е да имате безопасност на нишките предварително и да не синхронизирате нишките ръчно, като използвате блокиращ буфер или нещо подобно.


person Anton    schedule 13.12.2011    source източник


Отговори (1)


Каква е скоростта на трансфер в байт/секунда на вашето устройство? Ако е по-малко от 1 MB в секунда, вероятно няма значение кой подход ще изберете.


Ако пишете байтове, защо не използвате ConcurrentLinkedQueue<Byte> Всяка възможна стойност на байт се кешира, така че има само условна цена за автоматично опаковане и разопаковане.

Основното затруднение в производителността са свързаните записи в опашката. Всеки байт все още създава обект (който е възелът в списъка) и всеки обект използва около 16 байта. С други думи, можете да направите своя byte[] 16 пъти по-голям и той ще използва същото количество памет и ще създава по-малко боклук.

За да изпълните изискванията си, можете да използвате ConcurrentLinkedQueue<Byte>, но създаването на пръстен буфер за byte[] ще бъде по-бързо (и лесно за преоразмеряване)

Ако изпращате повече от 10 MB/s, бих предложил да напишете ByteBuffer и да обменяте с друга нишка (т.е. така че прехвърляте големи блокове наведнъж)

person Peter Lawrey    schedule 13.12.2011
comment
Очаква се кодът да работи на устройства с Android. Така че подателят може да бъде компютър (пише в порта), а получателят може да бъде много бавно устройство (чете от порта). Byte queue е по-добра от Integer queue, но пръстенният буфер е най-добрият избор според мен. Благодаря ти - person Anton; 13.12.2011