BibDesk becomes nonresponsive when trying to save a new bibliography into a folder from Google Drive File Stream. Any idea why this happens? Would it be possible to fix it up?
I have no idea. I don't know how Google Drive File Stream works. Can you
attach a sample taken while BibDesk hanfs? You can find instructions on the
Wiki.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can see where the wiki link is but there are many pages on the wiki, could you reference the precise wiki page where there are instructions about taking a sample as you asked for? it is not clear to me at this point what "a sample" is exactly
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
many thanks for clarifying, I was able to take a sample, in fact I took two (attached).
in fact it does not hang forever, just for very long time.
this happens when saving a large bib file ~12Mb inside a Google Drive File Stream folder containing ~10k PDF files (which are linked from within the bib file).
the folder is marked as "available offline", so all its content is already cached.
when doing saving the bib in a normal folder it takes ~5sec, while now it goes on for > 20 mins.
it would be interesting to see where the bottleneck is for such behaviour :)
The problem has indeed to do with the (many) linked files. Are they on a different volume? Also, when you save, do you save to a different location (i.e. Save As)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the bib file and the linked files are all in the same folder on Google Drive File Stream;
it takes forever to save the bib file (no Save As, plain Save);
also adding an entry and switching back and forth the window focus causes BibDesk to get unresponsive.
my guess is that GDFS is much slower than the host filesystem to resolve certain queries (which perhaps are cached normally) and that BibDesk upon save does some check on all linked files.
the problem does not occur for a small number of linked files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for quickly improving this, it is now much faster to (auto)save a big bibliography in the same location. In fact, this improved the performance even when the folder was not on Google Drive File Stream :)
However, it still took ~7min to autofile a PDF file when I drop it on an entry in this big bibliography (options: autofile in the same folder as the bib file). Would it be possible to speed it up this scenario too? There may be several portions of code which can be avoided when the base path does not change :)
Last edit: Lorenzo Clemente 2020-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, so I guess for the time being we will need to wait for improvements in Google Drive File Stream (which is very appealing since one can work with large digital libraries that are stored on the cloud via an local file system interface )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think we can do much more. Resolving aliaseses on GDFS seems to be extremely slow. I don't know why, perhaps it creates new file objects all the time rather than updating existing files. One thing you could do is to not use linked files, and use the Local-Url field instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have no idea. I don't know how Google Drive File Stream works. Can you
attach a sample taken while BibDesk hanfs? You can find instructions on the
Wiki.
sure, could you please point me more precisely in which page on the wiki are such instructions?
It's linked to at the top of the bug tracker
I can see where the wiki link is but there are many pages on the wiki, could you reference the precise wiki page where there are instructions about taking a sample as you asked for? it is not clear to me at this point what "a sample" is exactly
At the top of the bug reporter there is a link to the guidelines, which
includes a section on taking a sample.
many thanks for clarifying, I was able to take a sample, in fact I took two (attached).
in fact it does not hang forever, just for very long time.
this happens when saving a large bib file ~12Mb inside a Google Drive File Stream folder containing ~10k PDF files (which are linked from within the bib file).
the folder is marked as "available offline", so all its content is already cached.
when doing saving the bib in a normal folder it takes ~5sec, while now it goes on for > 20 mins.
it would be interesting to see where the bottleneck is for such behaviour :)
The problem has indeed to do with the (many) linked files. Are they on a different volume? Also, when you save, do you save to a different location (i.e. Save As)?
the bib file and the linked files are all in the same folder on Google Drive File Stream;
it takes forever to save the bib file (no Save As, plain Save);
also adding an entry and switching back and forth the window focus causes BibDesk to get unresponsive.
my guess is that GDFS is much slower than the host filesystem to resolve certain queries (which perhaps are cached normally) and that BibDesk upon save does some check on all linked files.
the problem does not occur for a small number of linked files.
Perhaps the next nightly build can be much faster on an ordinary save to
the same location. Could you try that out?
sure, when will I be able to download it and run the new version?
Hopefully tomorrow. There is a link on the homepage.
Thanks for quickly improving this, it is now much faster to (auto)save a big bibliography in the same location. In fact, this improved the performance even when the folder was not on Google Drive File Stream :)
However, it still took ~7min to autofile a PDF file when I drop it on an entry in this big bibliography (options: autofile in the same folder as the bib file). Would it be possible to speed it up this scenario too? There may be several portions of code which can be avoided when the base path does not change :)
Last edit: Lorenzo Clemente 2020-04-21
I don't think we can do anything about this. It looks like this drive takes
a very long time to mount. I really think there is a problem with it.
OK, so I guess for the time being we will need to wait for improvements in Google Drive File Stream (which is very appealing since one can work with large digital libraries that are stored on the cloud via an local file system interface )
I don't think we can do much more. Resolving aliaseses on GDFS seems to be extremely slow. I don't know why, perhaps it creates new file objects all the time rather than updating existing files. One thing you could do is to not use linked files, and use the Local-Url field instead.