summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-02-16 23:36:05 +0100
committerwm4 <wm4@nowhere>2020-02-16 23:36:05 +0100
commit20eead18130fd460d8e9eff50ce14afd3646faab (patch)
tree54a34a31b7c758bf5abdb943ca14c4f48fcb250e
parent249bb091d4880a564c00f8354111e12cfd0183a3 (diff)
downloadmpv-20eead18130fd460d8e9eff50ce14afd3646faab.tar.bz2
mpv-20eead18130fd460d8e9eff50ce14afd3646faab.tar.xz
stream_file: use fstat() instead of lseek() to determine file size
It appears using lseek() to seek to the end and back to determine file size is inefficient in some cases. With CIFS, this restores the performance regression that happened when the stream cache was removed (which called read() from a thread). This is probably faster than the old code too, because it's the seeking that was slowing down CIFS. According to the user who tested this, the size caching does not help with fstat() (although it did with the old method). Fixes: #7408, #7152
-rw-r--r--stream/stream_file.c11
1 files changed, 8 insertions, 3 deletions
diff --git a/stream/stream_file.c b/stream/stream_file.c
index 6e69f33c94..9f83b73dd1 100644
--- a/stream/stream_file.c
+++ b/stream/stream_file.c
@@ -77,9 +77,14 @@ static int64_t get_size(stream_t *s)
{
struct priv *p = s->priv;
if (p->cached_size == -2) {
- off_t size = lseek(p->fd, 0, SEEK_END);
- lseek(p->fd, s->pos, SEEK_SET);
- p->cached_size = size < 0 ? -1 : size;
+ int64_t size = -1;
+ struct stat st;
+ if (fstat(p->fd, &st) == 0) {
+ if (st.st_size <= 0 && !s->seekable)
+ st.st_size = -1;
+ size = st.st_size < 0 ? -1 : st.st_size;
+ }
+ p->cached_size = size;
}
return p->cached_size;
}