Posted by LordOfBikes on Jun 26, 2021; 12:55pm
URL: https://forum.librecad.org/LibreCAD-Slow-Saving-Across-a-Network-tp5714702p5720797.html

Many thanks for your efforts!

After some more searching, Windows 10 and Samba seems not to be best friends.
There are so many issues and different solutions, but obviously none matching our issue.
Found no similar issues related to other software using Qt or standard gcc libraries.

I have to look if I can find a appropriate development environment which shows this issue to trace the source code and profile where the time is wasted.
My assumption now is, that final writing happens in libdxfrw, which does not use Qt, but gcc standard c++ libraries for writing.
On the other hand, when local writing works fine, what shall we do?
From applications point of view writing is to open a stream, write data and close the stream.
There is no differentiation in source code if we write to local disk or network share.


Well, writing the above lines, triggered an idea for a new search and I found this:
https://serverfault.com/questions/808633/small-writes-to-smb-network-share-are-slow-on-windows-fast-over-cifs-linux-moun
After a look into libdxfrw code this seems to be the cause for our issue.
Anyhow, to prove and possibly solve this issue I need a Windows 8 or 10 development environment.

But to clarify, this is caused by Windows OS and finding a solution for libdxfrw can only be a workaround and we have to check if this influences other OS.
The operating system has enough information to evaluate if the causing std::endl should flush the stream or not.
Flushing with end of line is fine and needed for terminal devices, but a performance killer for regular files, especially over network, because it bypasses buffering.
This is exactly how Linux and presumably OS X handle it, flush on terminal devices, no flush on regular files.

There is already a GitHub issue to track this, I'll cross link this thread with the issue:
https://github.com/LibreCAD/LibreCAD/issues/1205