https://bugs.documentfoundation.org/show_bug.cgi?id=170652
--- Comment #4 from Utku B. <[email protected]> --- (In reply to m_a_riosv from comment #3) > I can't reproduce with > Version: 25.8.5.1 (X86_64) > Build ID: cde5f182e321816108385dd3739c4295be919062 > CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: > Skia/Raster; VCL: win > Locale: es-ES (es_ES); UI: en-US > Calc: threaded > > BTW, there are a lot of duplicated images in slide 7. Thank you for the feedback. I have now tested this with the Flatpak version as well, and the issue persists. Updated Environment: Version: 26.2.0.3 (X86_64) Build ID: afbbd0df0edb6d40b450b0337ac646b0913a760c CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded Additional Observations on Saving Performance: I’ve noticed that the storage medium significantly impacts the save duration, even for a single-word change: SSD: Saving takes approximately 10 seconds, which still feels excessive for a minor text edit in a 56 MB file. USB Thumb Drive (LUKS Encrypted): Saving takes several minutes. Technical Detail: By monitoring the directory during the save process (refreshing with F5), I can see the hidden temporary file gradually increasing in size until it reaches the full file size. This confirms that LibreOffice is rewriting the entire 56 MB archive from scratch for every save operation, rather than performing an incremental update. While I understand that .odp files are compressed archives, the I/O overhead—especially on encrypted or slower external drives—makes working on larger presentations nearly impossible. The fact that a one-word change triggers a full rewrite of a 56 MB file seems to be the root cause of this performance bottleneck. -- You are receiving this mail because: You are the assignee for the bug.
