https://bugs.freedesktop.org/show_bug.cgi?id=70224

          Priority: medium
            Bug ID: 70224
          Assignee: [email protected]
           Summary: LibreOffice 1-byte disk reads
          Severity: major
    Classification: Unclassified
                OS: Windows (All)
          Reporter: [email protected]
          Hardware: All
            Status: UNCONFIRMED
           Version: unspecified
         Component: framework
           Product: LibreOffice

When opening an ODT or ODS file (with LibreOffice) in Windows Explorer by
double-clicking it, the Explorer will actually freeze for some time, before
anything happens. 

On virtual (and sometimes even physical) machines, this frozen state can
persist so long that Dokan based file systems (Dokan on Windows is similar to
FUSE under Linux) will crash (which for some reason seems to be the default
behaviour of Dokan if an answer to some low-level file operation takes too long
to complete). 

I need those Dokan based file system to work, so I checked the reason why a 12K
ODS file with just some numbers in it (no scripts, no images, just plain text)
takes considerably more than 10 seconds to load in LibreOffice. As it turns
out, LibreOffice does quite a number of 1-byte reads (read() system calls) with
a 4K-buffer. 

These 1-byte reads start at some byte N and continue for sometimes a few dozen,
but mostly a few thousand bytes. This leads to about the following process (N
may be any byte in the file, most of the time, but not always, within around
the last 2000-4000 bytes, M is observed to be between about 20 and 4000):

seek(N)
read(buffer, 4096)
seek(N+1)
read(buffer, 4096)
.
.
.
seek(N+M, 4096)

LibreOffice will SOMETIMES do this anywhere in the file, even several times in
different places, and even repeatedly in the same "spot", but it will ALWAYS do
this with the last 2000-4000 bytes. Like this, the opening of a 12K file
produces around the same amount of file operations a 8-16 MB file would require
if loaded with a sequence of single, non-redundant 4K-reads. The main impact
seems to be the amount of system calls, NOT the amount of data returned (I
tried actually returning only 1 byte per read() call, the file took roughly the
same time to load).

I confirmed this behaviour of LibreOffice (versions 3 and 4) file (both ODS and
ODT) opening operations for Win7 Pro (64bit) and Win XP (32bit), both on
physical machines (Quadcore i5 with 4 GB RAM, SSD disks) as well as virtual
machines (KVM 1.2 on top of Gentoo Linux 64bit, virtio drivers installed in
guests). I did NOT check the Linux binaries, but since the file operation speed
of LibreOffice is comparably slow on Linux as it is on Windows, the assumption
is here that - at least to some degree - the same or similar situation applies
to Linux installations.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to