add caching of bib candidates

[emacs-citar]

add caching of bib candidates

[bdarcus]

OK, thanks much! That's what I see.

Not terrible, but I'd like performance to be consistently very good to excellent.

If you see the linked PR, I've figured out what causes this, but not yet why, or what can be done about it.

[bdarcus]

@wenjie2wang can you please see here?

#70 (comment)

It should be working here.

[wenjie2wang]

Thanks for your quick response! FYI, my bib file is available at https://gitlab.com/wenjie2wang/bibrary/-/raw/master/bib/index.bib.

[bdarcus]

OK, thanks.

I think I actually know what's going on. Will check in a bit.

[bdarcus]

I just loaded your file, and every time I load a command, there's a pause, but it's certainly less than a second.

What do you mean by "noticeable time"?

[bdarcus]

That said, I do think we've identified a performance bottleneck, that when fixed should address this.

[wenjie2wang]

I just loaded your file, and every time I load a command, there's a pause, but it's certainly less than a second.

What do you mean by "noticeable time"?

Thanks, @bdarcus ! This is what I mean by "noticeable time". There is always a noticeable pause after M-x bibtex-actions-open. In contrast, M-x ivy-bibtex is able to respond instantly after the first run. I made a gif for your reference.

[bdarcus]

I've been digging into this (doing benchmarking and profiling), and I can't see an obvious way to improve this on my end without unnecessary complexity. But I do see that a simple change in bibtex-completion could address this.

The situation

We have two functions that generate this UI:

1. bibtex-completion-candidates: this one is cached, and is fast
2. bibtex-actions--get-candidates: this one is not cached, and is slower, because it transform 1 to do the display formatting

Because of how completing-read is designed, I need 2, though, because it doesn't have any notion of display transformers as in helm and ivy. So there is no distinction in completing-read between searching/filtering and display.

So part of the problem is intrinsic to completing-read.

The other part is that bibtex-completion-candidates is designed around the above feature that is in helm and ivy, but not in completing-read.

Proposed solution

Ideally, however, I'd be able to replace the candidate strings in bibtex-completion-candidates, with the output of bibtex-actions--get-candidates. That would allow all of the display data to be cached, and so address the pause you note.

@tmalsburg - would it be possible to add a hook to bibtex-completion (a la the sort of thing you see in org-mode) that would allow me to specify a different function to generate that string? Something like:

(add-hook 'bibtex-completion-candidates-hook #'bibtex-actions--format-candidate)

If yes, that would be a simple and elegant solution to this issue.

Edit: per below, however, I decided to add my own cache.

Conclusion

In the end, I don't think the slight delay is a deal breaker, but would ideally like to address it, without myself having to write my own caching code.

PS - I have tried different ways to speed up bibtex-actions--get-candidates, but none have an appreciable difference, so I don't think that's a promising path. It's basically fast enough, even for very large libraries, so long as we can activate caching on it.

[bdarcus]

I've opened a linked pr that adds a cache. A hook could still be useful, but if this works, it's a small enough addition that I'm happy to merge it.