Appending from remotely saved Blender files has massive loading issues #88294
Labels
No Label
legacy module
Animation & Rigging
legacy module
Core
legacy module
Eevee & Viewport
legacy module
Modeling
legacy module
Platforms, Builds, Tests & Devices
legacy module
Rendering & Cycles
legacy module
User Interface
legacy module
VFX & Video
legacy project
2.81
legacy project
Animation & Rigging
legacy project
BF Blender: 2.8
legacy project
BF Blender: After Release
legacy project
BF Blender: Next
legacy project
Core
legacy project
Cycles
legacy project
EEVEE & Viewport
legacy project
Modeling
legacy project
Modifiers
legacy project
Overrides
legacy project
Platform: Windows
legacy project
Render Pipeline
legacy project
User Interface
legacy project
Video Sequencer
Priority::Normal
Status::Archived
Status::Duplicate
Status::Resolved
Type::Bug
Type::Patch
Type::Report
No Milestone
No Assignees
9 Participants
No due date set.
Dependencies
No dependencies set.
Reference: archive/blender-file#88294
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows, MacOS
Graphics card: all kinds
Blender Version
Broken: 3.0
Worked: never
Short description of error
If I am trying to append anything from Blender file remotely on a network drive, chances are that it will be incredible slow or even freeze Blender completely. This is massive issue that has been hindering our production. As a medium game studio we are using one remote drive with all our working files. Many times we need to append some parts of one Blender file to another however because of the remote character it is for some reason incredible slow to brows through the file's hierarchy. Many times opening subfolder in the file's hierarchy takes many minutes, and very often it freezes the whole software. The only solution right now is to download the file offline and append from it, but that is really inconvenient for studio like ours to do this with every file.
Exact steps for others to reproduce the error
Open Blender
Try to append from a remotely accessible file
Browsing through the file hierarchy may cause long lags or freeze. Bigger the Blender file is, more likely it is that it will freeze. Causing problem even on a very fast network
Added subscriber: @MirekDusin
Added subscriber: @Harley
Could you provide more information about your setup? A blender file can be "remotely on a network drive" in many different ways. Is your computer and the network drive on the same physical network and single location? Are you connected to it with network cabling or though wifi? How fast of a connection?
You mention that the "only solution right now is to download the file offline". Generally we only talk about files being online or offline when using a cloud-based service (file sharing over the internet). Is that how you share files? Or do you mean just copying the file to a drive that is on your computer?
Changed status from 'Needs Triage' to: 'Needs User Info'
The remote drive is not in the same location but accessible over the internet. However, the connection is pretty fast. The remote server is connected over an optical cable (not sure about the speed but it should be over 100 Mbps) and all the parties connecting to it have at least 20 Mbps download / upload. Browsing through regular files is pretty fast, happen almost instantly, the problem occurs when one is browsing through the blender file hierarchy.
By offline I mean downloading this file to my local drive from the remote drive.
Changed status from 'Needs User Info' to: 'Needs Triage'
This behavior sounds perfectly normal and expected in the described situation.
The first thing to keep in mind is how different it is to browse your file system versus browsing inside a blend file. Blender makes these two processes appear very similar, but they are actually vastly different. When connection speeds are at optimal (when files are local) these two processes take similar amounts of time. But as connection speed decreases file listings will still remain quite fast while "appending" will get much much slower.
When browsing file system lists your computer does not need to download the entire contents of every file in that folder. Instead your computer asks the remote host for a listing of the location, the remote computer gets a list of the contents and sends that list to you. The only things being transmitted are mostly the file names and some other associated attributes, sizes, and dates. This process is so easy and lightweight that you will find little difference in the performance if you have a very slow internet connection versus the files being locally attached. You and I would find no difference in performance if you have a 10Mbps internet connection and I have a 1Gbps network connection as the time to transmit a directory listing is so trivial.
But when "Appending" there is no similar client-server system where the remote server can look into the file for you and just supply a simple listing. Instead your computer itself is opening and browsing and downloading the contents of that blend file. For this you will most certainly notice the connection speed. If you have a 10 Mbps internet download speed and I have a 100Mbps internet connection then the time to get a listing of the contents inside a blend file will be 10x faster for me.
So, in a nutshell, when connection speeds are very fast the acts of browsing through file system folders and inside blend files while Appending will be similar. But as your connection speed drops file system listings will remain fast while appending will necessarily get increasingly slow. This is expected behavior.
You will see similar differences in speed when viewing normal file system folders if you are in "thumbnail" view. When the connection is really fast (like with a local connection or a fast network speed) the thumbnails will show up quite quickly. But as your connection speed decreases you will find being in thumbnail view to get more and more unbearable since the contents of all the files have to be downloaded.
Sorry but you seem to not understand the problem. What you describe is expected but how it actually behave is not expected. We were testing it today and Blender file we were trying to append from with a size of 22 MB froze the app. This should not be happening. If I would download a file that is 22 MB of size to some local storage, it would take seconds, instead Blender is usually taking minutes and that is only if you are lucky and it doesn't freeze the app. This is really an issue if you are working with group of people that are not sharing one office with local storage. If Blender should ever get to be used as a professional tool in larger studios, then those things need to be fixed. I am not sure if this is a bug or just limitation of current Blender and should be added as a new feature in the future using some sort of indexing, but this needs to be tackled.
I do understand the problem. I'm saying that for "Appending" the slow speeds you are experiencing are caused by the download speeds of your clients, which you say is "least 20 Mbps download." That speed sounds like wifi 802.11g. You can get faster with newer wifi. And even faster if you use a wired connection to the router instead. I get download speeds of about 350 Mbps. We would see an almost identical performance while viewing file system folders (not in thumbnail view) but while Appending mine would work 17X better.
Sry, I might have not made myself clear when talking about freezing. By freeze I mean the app stops responding and need to be force quit. So basically it is impossible to append remotely anything from a file of not even that significant size. This is the major issue here, not that I need to wait. I understand that there will always be some delay as long as there is no indexing. Even still the waiting is not really proportionate to the speed of my connection. I can easily download file of size around 20 MB within few seconds, even if Blender would download the file every time I move in the file's hierarchy, it shouldn't take minutes.
Just to back up a bit. I'm not doubting that you are seeing this behavior. And not arguing that it is acceptable behavior either; it sounds unbearable. And also not saying that changes aren't possible that could improve things, new approaches could be used, or even that a "blender resource server service" couldn't be created and run on your hosting server.
I'm just saying as blender is right now the downgrade in behavior is directly related to download speed, so increasing that speed should be a priority for you to get your work done. As you have tested, it is a smooth continuum from fast access when the file is on your local machine, to worsening as you move the file to slower and slower network speeds, to unbearable over wifi. All directly related to file access speed. The time it takes to seek and read parts of a file on your local machine is about 100X faster than doing so over a wifi connection.
Are you able to build blender from sources ? If so I could talk you through making small changes that might point us toward ways of improving this.
Added subscriber: @Zandman
The network connection speed doesn't seem to be the problem here. However, there might be a difference in the way the files are accessed. When you copy a file from a network location using Windows Explorer or the macOS Finder it just treats the file as a large BLOB and reads the files in one or more chunks sequentially.
I'm not (yet) up-to-date on the specifics of Blender's way of accessing files, but it might be Blender accesses files using random access. So it will first read the file's header to obtain information about the file (i.e. what collections, objects, etc. it contains). And based on that it might read the other parts of the file. Not in a sequential way, but maybe reading a part at the beginnen, a piece at the end, then some middle part, etc. This can have considerable overhead, especially in a network situation.
Another problem could be the fact that multiple people are accessing the same file simultaneously. If they are only reading it, it might result in network congestion. But if some are also writing to it and keep it open (and have a lock on it) it could result in file read errors or having to wait until a lock is released.
Just my two cents :-) Hard to tell what's going on without more specifics.
Yes, exactly, using memory-mapped files, so the operating system is swapping in 4KB pages at at time on access. This means a lot of little transfers that will be especially harmed by large latency. That is why I want some eyes on this patch: https://developer.blender.org/D11469 as I have been unable to set up a testing environment that will simulate OP's bad networks performance.
Hey, sorry for the radio silence. We can help with our art team to test the possible solution. I can check how to build Blender from source.
The following are instructions on building Blender for the Windows platform: https://wiki.blender.org/wiki/Building_Blender/Windows
I was unable to recreate network conditions as you describe here, and then my other testing computer died anyway. I put out a call for others to chip in but no replies yet: https://devtalk.blender.org/t/request-for-network-performance-testing/19086
I am mostly hoping you can apply and try the following patch to see if it makes any difference for you: https://developer.blender.org/D11469
One other thing that you could test that does not require compiling blender or making any changes....
Try this with a compressed file. As in open that library blend, save a version of it that is compressed (click the gear icon at top-right in the File dialog) and put it in the same network location as usual. Then test browsing into it and see if it is any faster. There is a good chance that this will be much faster because the client will download the entire thing into memory (which you have mentioned can happen in just a few seconds) before decompressing, saving all the little file transfers.
@MirekDusin - Still waiting for you to test.
Hello, sorry for the late answer, I was on holiday. I've tested appending from the compressed file as you suggested, but the result is the same. When browsing through hierarchy the file is still loading every time. Once people are back from holiday we can try to compile the Blender version where you made the changes. Thank you!
Every part of the file will load when appending, so your test should be timing of how long it takes. If appending from a remote compressed file is no faster for you than appending from a regular file then there is not much chance that my proposed changes will help.
Hey, just tested the timing, it helped a bit. I was testing it on a file that was 22 MB uncompressed and then 5 MB compressed. Loading the basic folder took 34 seconds when loading the uncompressed and 11 when compressed. When loading the folder with objects it took 2:12 to load for uncompressed and 1:45 to compressed. So there is a difference, but it is not that significant in sense of usability.
Interesting.
This would actually make me guess that the changes in this patch won't help you as the difference in that 11 to 34 seconds is fairly close to the difference in file download size. When compressed it is just downloading the entire thing in one go, while when not it is using those memory-mapped files. It was the latter I was worried about the efficiency on slow connections with high latency, but this seems to show that there isn't much to improve there.
Would still be nice to know though for sure though, so still looking forward to you testing it. But not holding out a lot of hope.
One thought it is to change your process a bit to using a service like OneDrive to host your shared files. Although there wouldn't be a real difference is raw speed of course, it could be more convenient because these services manage local cached copies for you. If the file changed it would make you wait the 34 seconds as it downloaded but then it would act as if it were local.
Added subscriber: @brecht
Have you tried comparing with an older Blender version like 2.83? A version before memory-mapped files were used for reading .blend files.
I know that in some Windows versions, accessing memory-mapped files on a network drive bypasses the cache manager regardless of what you do. If that's still the case, it could make sense to use file streams when we know the file is on a network drive.
EDIT: though I guess compressed files don't use memory-mapped access, so maybe that's not the issue. Still could be worth checking older Blender versions to see if was better at some point.
It was the same issue before 2.83
Thank you for the work and help but yeah, I am afraid this will not solve our issue. And having everything on OneDrive or other platform is not really plausible for us since we have the network drives not only for sharing but also to offset the storage from our computer. The data we have there are quite large so having it copied to a local drive wouldn't be possible.
I wish there would be some better solution in the future, maybe part of the Blender file would be some log that would map the structure of the file at save and then when accessed would just let the user browse through it before calling the exact part of the Blender file that is demanded. It would definitely help lots of studios that are not working from one location and need accessing shared files.
Anyway I will let you know when our technical artist is back from holidays and we can compile and test your version
Added subscriber: @CharlesHyde2
This comment was removed by @CharlesHyde2
Added subscriber: @OmarEmaraDev
Changed status from 'Needs Triage' to: 'Needs User Info'
@MirekDusin Did you get a chance to compile and test the patch provided by Harley? I know there wasn't a lot of hope for it to fix the issue, but just for completeness.
Added subscriber: @ThomasDinges
Changed status from 'Needs User Info' to: 'Archived'
No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.
Thanks again for the report. If the problem persists please open a new report with the required information.