LibreCAD Slow Saving Across a Network

I have LibreCAD on a wired 1GB network. Using the same AutoCAD DWG source files I opened then saved them as DXF files to two different locations. The first location was a network share and it took as much as 10 minutes to save. The second location was the local hard drive and it took no more than about 10 seconds to save.

Any idea of why the difference? It is really irritating to have LibreCAD autosave and take minutes to save after making a few changes.

This is driving me crazy.  I have a QNAP NAS serving up a network drive.

I use Windows 10 Pro version 21H1 on an AMD Ryzen 7 4800H with Radeon Graphics, 2.90 GHz, 16.0 GB RAM with LibreCAD: Version: 2.1.3, Compiler: GNU GCC 4.9.1, Compiled on: Sep 23 2016, Qt Version: 5.4.1, Boost Version: 1.60.0

Loading a LibreCAD file is very quick, but saving the same very small LibreCAD created native dxf file (only 71Kb!) to the network drive takes about 30 seconds ... saving it locally is essentially instant.

Word, Adobe Acrobat, and several other 3rd party applications save to the network drive very quickly - 20Mb files save in 3-5 seconds.  Copying large files to and from the network drive is also speedy.

I have tried wired and wi-fi connections, installed LibreCAD on two different computers, changed the SAMBA version on the NAS from v2.1 to 1 to 3, tried the LibreCAD nightly build, tried a registry change for "DirectoryCacheLifetime" ... nothing helped.  The best I can tell is it is unique to LibreCAD.

Any ideas?

Thanks!

I have experienced the same problem.  I have a large file (22 MB) that takes minutes to save to a Samba share from a Windows 10 PC.  However, it only seems to be a problem with the Windows (10) PC.  I have not had the problem with my Linux PC saving the same file to the same share.  It is a quick operation.

[LC 2.2.0rc2 on Debian 11]

Thanks for pointing out that I'm not the only one. Anyone else experience this?  Any *simple* workarounds and still be able to save to a network drive?  Report as a possible bug?

I'm on Linux too, but this may help:
https://www.google.com/search?client=firefox-b-d&q=windows+10+slow+network+share

Thanks, but I did try that and it did not help. I'll try some other things and see if I can find a workaround and post if I do.  

I'd suggest to try the latest version from here:
https://sourceforge.net/projects/librecad/files/Windows/NightlyBuilds/master/

But because I can't say which version @GaryS used on Windows, it may already be negative proved by him.
In fact the latest version is build with Qt 5.12, when older 2.2.0-rc versions were still built with Qt 5.4, so it could be worth a try. It is in release candidate state and as stable as 2.1.3.

LordOfBikes wrote

I'd suggest to try the latest version from here:
https://sourceforge.net/projects/librecad/files/Windows/NightlyBuilds/master/

But because I can't say which version @GaryS used on Windows, it may already be negative proved by him.
In fact the latest version is build with Qt 5.12, when older 2.2.0-rc versions were still built with Qt 5.4, so it could be worth a try. It is in release candidate state and as stable as 2.1.3.

No joy - same symptoms.  Thanks again.

It is LC2.2.0rc2, on Windows 10:

... writing to a SAMBA share on a Linux server.

For what it's worth, I timed saving a file (22 MB) at 155 -225 KB / min.  So, if I do the math right, that's about 2 hours to write this file to a share.  I gave up after 5 minutes.  From Linux, it is seconds.

I'm going to set up a share on a Windows 10 PC and see the problem exists writing to a Windows share.  I'll post the results later...

Gary S wrote

It is LC2.2.0rc2, on Windows 10:

... writing to a SAMBA share on a Linux server.

For what it's worth, I timed saving a file (22 MB) at 155 -225 KB / min.  So, if I do the math right, that's about 2 hours to write this file to a share.  I gave up after 5 minutes.  From Linux, it is seconds.

I'm going to set up a share on a Windows 10 PC and see the problem exists writing to a Windows share.  I'll post the results later...

Some more data:

Writing the same small dxf file using the same network and the same PC to the same network drive:

... using LibreCAD under Windows 10 is very *SLOW* (10's of seconds).
... using LibreCAD under Linux Mint  is fine (under 1s).
... using QCad under Windows 10 is fine (under 1s).

Based on this data, it seems to be a reasonable conclusion that the I/O implementation within LibreCAD under Windows 10 is the cause.

I set up a Windows (10) PC with a file share and wrote to it using a separate Windows 10 PC using LC 2.2.0rc2, and the problem persists - writing to a SAMBA or MS Windows shared drive from a Windows 10 PC is sloooow.  So, yes, it appears to be LC on Windows 10 (LC itself or a Qt library?)

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

I had searched and found some similar results earlier.  I didn't keep the references, but from what I was able to find it might be an issue with local drives too (HDDs and SSDs / NVMe) - it is just that the local drive are fast enough the problem isn't apparent.

Update:
I tested saving a 22MB file to a local drive with the following results:
   Linux: 3 sec
   Windows 10: 10+ sec

Different PCs, but both have NVMe drives with LC 2.2.0rc2 installed...

Another data point: I had to do a clean install of Windows 10 Pro and after doing the install and applying all the Windows updates, I installed LibreCAD-Installer-2.2.0-rc2-19-ge02f3580.

Saving to the network drive took about 5 seconds for the 71Kb DXF file which is much better than 40+ seconds.

A 2nd PC on the same network with the same version of windows that has been used for 6+ months is still very slow.  Seems like a fresh install improves write time.

Still a puzzle though, as QCad with the same file doesn't have any significant writing problems to the same drive.