Periodic slow searches and temporary freezing

dstillman
This discussion was created from comments split from: New Zotero 5.0.72 very very slow to update and search.
  • ncraig
    I'm experiencing similar issues with periodic slow searches and other unexpected temporary freezing of the application. The debug id = D1087138051

    Thank you for a fantastic product and for looking into this matter.
  • dstillman
    (3)(+0000027): Translate: Beginning translation with Better CSL JSON

    (3)(+0013155): Translate: Translation successful
    Since your report isn't about Zotero startup, we would need a Debug ID for a specific operation that's slow, not for Zotero startup. But note that you have multiple plugins installed, and at least at one point there's a 13-second delay during which BBT appears to be exporting something, so I'd guess that something in BBT is causing the slowdown.
  • emilianoeheyns
    edited August 18, 2020
    On the other hand, unless it's turned off, that export should have happened in a worker thread that wouldn't bother the main thread. The +0013155 is wall-clock time, but not necessarily (not usually in fact for BBT) time spent in the main thread.
  • emilianoeheyns
    edited August 18, 2020
    Though that had better be a first (couple of hundred items) or otherwise fairly large export (couple of thousand items), or 13 secs would be very slow, regardless of the fact that it should be happening in an isolated thread.
  • ncraig
    Sorry if the prior debug id wasn't appropriate. Part of the issue is that Zotero is sluggish when I haven't been using it in a while. Once it is used again, after an initial wait it responds more snappy. Getting that logged in a debug session took some planning. This morning I submitted a new search that was slow and I hope captured by the debugger, the ID for this session is D723709095.

    Thank you again for your attention to this and for an incredibly useful product.
  • ncraig
    @dstillermann yes, there are a number of extensions installed. Startup is slow and does seem to be related to BBT, specifically site keys. Zotero often wants to restart because of site key issues. BBT is set to keep updated some files that are used in conjunction with the Zettlr markdown editor. I realize this startup matter is a separate issue, but did want to respond to the observation about BBT.
  • emilianoeheyns
    As long as the startup message says "waiting", BBT is not doing anything, it's just waiting for the go-ahead from zotero - that time can't be counted against BBT slowing down the startup. If the "loading citekeys" takes more than a second, two if it's a large library, I'd appreciate it if you could open an issue on github. That's something I'd want to look into. I have some 4k items in my library and for me the "loading citekeys" is barely up long enough to read.

    I'm not sure what is meant by "zotero wants to restart because of citekey issues". If there are citekey issues that means BBT is involved, but I don't prompt for a restart unless one of its translators have been updated, and that doesn't happen often these days. For citekey issues (of whatever kind) I don't prompt for restart ever.
  • dstillman
    edited August 21, 2020
    This morning I submitted a new search that was slow and I hope captured by the debugger, the ID for this session is D723709095.
    Can you describe more what you did and what the problem is?

    I see a search (first for "per" and then for a longer search string), and then results within a second or two.
  • dstillman
    Zotero will start searching shortly after you stop typing in the search bar. If you're finding it's doing that sooner than you'd like, you can prefix your search with " to have Zotero wait to perform the search until you press Return. The default behavior is meant to strike a balance between giving you time to type and not making you wait too long after you stop typing.
  • emilianoeheyns
    I can't access those logs BTW, so if BBT seems to play a role, you'll have to submit a separate BBT debug log.
  • ncraig
    edited August 24, 2020
    @dstillman Getting results when typing in search terms is taking much longer these days than it has in the past. I probably didn't capture the best example of what I'm talking about, but that is the gist of the issue. When typing "performance" the wheel now spins for much longer than it used to--or than I'm accustomed to. This is more of an issue when I'm away from the program for a bit and then come back to it after some time. Once I've started interacting again with Zotero, the searches are a bit snappier. It is generally the first or first couple of searches that are slower than in the past. Zotero is always running on my machine.

    Thanks very much.
  • ncraig
    edited August 24, 2020
    @emilianoeheyns sorry if I am not explaining things accurately. I have two libraries about about 10,000 items, they are an accumulation of things going back to Endnote Plus, ca 1995.

    I probably didn't explain the citekey matter correctly. Update of translators is the message that is reported with the request to restart. This hasn't happened in a few days. Thanks for clarifying. I see there is an option to send a debug report for BBT. Should the need arise, I will use that tool.

    Thank you.
  • dstillman
    This is more of an issue when I'm away from the program for a bit and then come back to it after some time.
    That sounds like a RAM issue. When you're actively using Zotero, the database file may be stored in the OS file cache, and when you switch away and start using other things that's cleared. It could also be application memory, but that's less likely for something like searching that always searches the database file.

    How much RAM do you have in this computer?

    I'd guess that if you close all other programs and try immediately after restarting your computer, you won't see this sort of difference after switching away (to something that doesn't use a huge amount of RAM).
  • emilianoeheyns
    Update of translators is the message that is reported with the request to restart. This hasn't happened in a few days.
    it only happens after an upgrade of BBT that also changes the bundled translators, and it happens only once. The translators can't do drag-and-drop after they're upgraded until you restart Zotero; if you don't care about drag and drop of bibtex stuff, or you intend to restart zotero anyway later, you can just check the "don't ask me again" box, and you will not be asked again.
  • ncraig
    @dstillman what you say makes sense.

    Increasing the ram, the application is significantly snappier. Thanks, this was a big help.
  • ncraig
    edited December 13, 2020
    The ram increase made a welcome difference, but Zotero was still regularly very slow to respond particularly when editing the info section or tagging an item. Switching from field to field lagged.

    I turned off all plugins and found the application much faster. In retrospect, this should have been my first step. I eventually, by doing this, I isolated the issue. What seems to have caused the performance hit was Automatic Export under Better BibTeX. I had two instances of exporting my entire library (~4k items) with the update option set to any change. Better BibTeX documentation states
    " While I’ve gone to some lengths to make sure performance is OK, don’t go overboard with the number of auto-exports you have going. Also, exporting only targeted selections over your whole library will get you better performance."
    I was using these exported libraries to work with Markdown applications like Zettlr and Obsidian. I found that disabling Automatic Export dramatically improved Zotero's performance when editing individual fields. Zotero is again the joy to use that I remember. Fortunately, I can still benefit from Better BibTeX by simply clicking Export Now when needing the library update when performing a pandoc export of a Markdown document. Not having the library up to date moment by moment has no impact on the use of citekeys while writing. At least in my instance, automatically updating large libraries (on an older computer), appears to be the culprit.

    I do still get slowed performance when Automatic Export is set to "idle" and I'm not sure why. It would be nice to have the export process automated even if not moment by moment. Also, I had Zettlr and Obsidian reading different export formats. Zettlr was reading Better CSL JSON while Obsidian was reading Better BibTeX. I set them both to Better BibTeX. Doing so, I am getting better results (fewer errors) in Zettlr. Anyway, I wanted to provide an update on what worked as it may help others experiencing a slowing of Zotero. Thanks for a great community and all the hard work of those who work on Zotero core and useful plugins like Better BibTeX.
  • emilianoeheyns
    4k doesn't sound too big to do this, certainly with BBT background exports. If you open an issue on GitHub, we can look whether you're hitting the cache, and whether background exports are being used.
  • ncraig
    edited December 13, 2020
    Thank you. I looked at the BBT Advanced Export settings. I turned on Parallel background exports, with a single slide to the far right. I'd never looked into these settings. Now background exports are enabled. Then I reactivated automatic export set to On Change. So far, things appear to be humming along.

This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.

Sign In or Register to comment.