You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It wouldn't be too much trouble to expose a ws_conn_sendfile function that takes a file descriptor, size, and an opcode, write the header then call sendfile on the provided fd. can be useful for sending static data and we don't have to waste event loop time copying in userspace.
sendfile is cool but copying maybe better for smaller files, especially for file content already in memory, in fact similar to writev I bet for smaller buffers it's faster to just memcpy then send. I have tested this in the past but don't have any numbers atm. won't hurt to include that as a fair warning in docs so no one goes crazy with sendfile thinking it's making things faster.. its ideally something people test for their own use case before jumping straight in because they heard it's faster or it's faster "in theory".
overall I think sendfile can be valueable if:
the file is not opened or read, in this case we open to get an fd then sendfile (2 syscalls) and not have to read it esp if we don't care about the content. we just let the kernel deal with it.
the file is large (can't put a number on large where sendfile is faster without testing)
many connections are being sent the same static file (again it may still be faster to just copy it each time depending on size)
It wouldn't be too much trouble to expose a
ws_conn_sendfile
function that takes a file descriptor, size, and an opcode, write the header then call sendfile on the provided fd. can be useful for sending static data and we don't have to waste event loop time copying in userspace.sendfile (2)
The text was updated successfully, but these errors were encountered: