[Bug 794173] filesink pointlessly uses write/writev

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=794173

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #3 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Do we know anything about the fwrite implementation ? One of the problem is
that fwrite() never becomes owner of the data, hence is requires to copy that
data into another buffer (higher CPU).

I think it would be extra nice if we gain the same syscall optimization, but
without loosing writev optimization for zero-copy. But that would be quite some
work for such a niche use case (high throughput disk writing). So I'd say yes,
fwrite might be the right way.

I've also tested it locally, as I know Linux 4.14 is supposed to have some
patch to help throughput with large amount of queued IOs, but it's still twice
faster without your patches here. Interesting data is the number of write call
we do:

Before:
$ strace gst-launch-1.0 fakesrc sizetype=2 sizemax=4 num-buffers=40 ! filesink
location=testfile.raw 2>&1 | grep write | wc
     22092  116783 1080171

After:
$ strace gst-launch-1.0 fakesrc sizetype=2 sizemax=4 num-buffers=40 ! filesink
location=testfile.raw 2>&1 | grep write | wc
     95     527    4522

The includes couple of print f of course, but it gives an idea that there is
something wrong.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.