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.