Hey everyone, I've been seeing a few folks mention this in passing, and I've definitely felt it myself. As my library in ResearchRabbit has grown (I'm pushing 800+ papers now), the interface has started to feel really sluggish. Adding a new paper, scrolling through the graph, or even just opening the app can sometimes take a noticeable few seconds.
I'm trying to figure out if this is just the nature of the beast—maybe the visual graph and all those connections simply become computationally heavy beyond a certain point? Or is there something about how we structure our libraries that could help?
From a change management perspective, I worry about recommending it to colleagues with massive, established Zotero libraries if performance tanks. I love the discovery features, but the lag can really interrupt a smooth research flow.
Has anyone found a sweet spot for library size where it remains snappy? Or any tips on managing larger collections within the tool? Maybe periodic "cleaning" or splitting libraries by project? I'm curious about your experiences and any workarounds you've developed.
ian
ian
800 papers isn't that many. The problem is likely their architecture. Visualizing a graph client-side for that many nodes and edges shouldn't cause noticeable lag if it's done right.
You're already hitting the ceiling. It's not going to get better with a 5k Zotero import. Tools that can't scale with basic use aren't ready for production. Splitting libraries is a workaround for their poor design.
Have you tried the browser console to see what's hanging? Bet it's a memory leak.
Don't panic, have a rollback plan.
I feel that lag too around the 700-paper mark. Splitting by project helped a ton for me, actually. I keep my main "active lit" library under 300 items and archive old projects into separate libraries. It's not ideal, but the graph stays usable and adding papers is snappy again.
I'm hoping their team is working on some backend optimization for this. The discovery features are so good, but the performance wall is real once you get invested.
Beta tester at heart
800 papers isn't that many. The problem is likely their architecture. Visualizing a graph client-side for that many nodes and edges shouldn't cause noticeable lag if it's done right.
You're already hitting the ceiling. It's not going to get better with a 5k Zotero import. Tools that can't scale with basic use aren't ready for production. Splitting libraries is a workaround for their poor design.
Have you tried the browser console to see what's hanging? Bet it's a memory leak.
Don't panic, have a rollback plan.
You're spot on about the recommendation problem. That lag is exactly why I stopped pushing it for team use last quarter. The graph is the killer feature, but it also becomes the bottleneck.
800 papers shouldn't be a stress test for a modern web app. User49's repeated point about architecture is probably right. The splitting workaround works, but you're then managing multiple graphs, which defeats the purpose of seeing connections across your entire research scope.
My 'sweet spot' was under 500 items. After that, the delay when adding a paper felt like watching paint dry. For a Zotero import, you'd have to pre-split everything, which is a non-starter for adoption.