[Mono-list] Array.CopyTo - Mono (Ubuntu) vs .Net (Windows)
aaron.oneal at spicypixel.com
Tue Jul 30 16:53:41 UTC 2013
Is there a reason your video source requires this technique to buffer? This code is inefficient because:
1. It allocates a new buffer every time it reads from the source buffer.
2. It removes data from the source buffer by doing 2 more heap and block copies.
I'm pretty sure overlapping regions are supported in a way that you can avoid one copy by doing an in-place BlockCopy for #2 instead of a second allocation.
But, the main issue is, why must you dynamically allocate new buffers and "remove" data from the source buffer in the first place? In the buffering scenarios I'm familiar with, you would normally allocate a fixed-size buffer which you would pass down to the underlying data provider along with the start index and length to fill. Once your buffer is full, you stop reading from the source until you drain your buffer. Your buffer is emptied not by copying data and re-allocating a buffer, but by simply moving the index for the start of your buffered data. Specifically, you might want to check out this article on circular buffers.
You really don't want to be performing heap allocations every read.
On Jul 27, 2013, at 10:56 AM, const86 <powerdeth at narod.ru> wrote:
> Write module buffering online video stream for the player. I write it as
> Buffer.BlockCopy (buf, 0, _buffer, _length, length);
> buf-what record
> _buffer - where to write
> _length - buffer size
> length - the length of bytes to write
> Reads the bytes from buffer:
> byte  outbs = new byte [_buffer.Length];
> Buffer.BlockCopy (_buffer, 0, outbs, 0, length); / / copy the block of a
> certain size
> / / Delete the data read from the buffer
> var buf = new byte [_buffer.Length];
> Buffer.BlockCopy (_buffer, length, buf, 0, _buffer.Length - length);
> _buffer = new byte [_buffer.Length];
> Buffer.BlockCopy (buf, 0, _buffer, 0, buf.Length);
> _length - = length;
> / / Return the read data
> return outbs;
> .Net (Windovs) this algorithm is very fast. So the difference that no buffer
> that is almost negligible.
> In a mono (Ubuntu), this algorithm operates so slowly that for every 2
> seconds viewing awaits player 5.
> Question. How to improve the algorithm in mono, that he was able to cope
> with the flow in rialtaym.
> P.S. Sorry for the bad English. This is the Google Translate. I do not know
> English so much on what to ask such questions :).
> View this message in context: http://mono.1490590.n4.nabble.com/Array-CopyTo-Mono-Ubuntu-vs-Net-Windows-tp4660316.html
> Sent from the Mono - General mailing list archive at Nabble.com.
> Mono-list maillist - Mono-list at lists.ximian.com
More information about the Mono-list