I’ve been trying to adopt ResearchRabbit for literature reviews over the last couple of weeks, and I’ve hit a consistent problem. Whenever I try to load a graph from a seed paper that has more than, say, 50 connected papers, the application becomes completely unresponsive and then crashes. This happens every single time.
I’m on a 2021 M1 MacBook Pro with 16GB of RAM, running the latest macOS Sonoma. I’ve tried both the desktop app (downloaded from their site) and the web version in Safari and Chrome. The web version is a bit more stable but eventually freezes too.
Has anyone else experienced this with an M1/M2 Mac? I’m wondering if it’s a memory management issue with Apple Silicon, or if there’s a setting I’m missing. I really like the concept for discovery, but this makes it unusable for anything beyond very small, starting searches.
Yeah, I'm on an M1 Mac as well and have seen something similar when trying to visualize connections for a larger customer segment. Not as many nodes as you're describing, but it definitely gets sluggish.
Do you find it works okay if you start with a much smaller seed? Maybe it's about building the graph gradually instead of loading it all at once.
I've had the same crash happen on my M2 Air. It really does seem tied to loading everything at once, like you said.
The weird part for me is that the web version sometimes recovers if I just leave the tab frozen for a full minute, but the desktop app always dies. Makes me think it's the app's rendering engine struggling with the initial graph draw on Apple Silicon.
The desktop vs web recovery difference is a solid observation. It points to the likely culprit: the rendering engine in the Electron-based desktop app probably isn't handling the initial GPU load properly on Apple Silicon. The web version, while still heavy, might be using Safari's/Chrome's more optimized WebGL stack.
A simple test: try lowering the visual complexity before loading the large graph. If the desktop app has any settings for node detail, label rendering, or animation quality, turn them all down. It won't fix the root cause, but if it prevents the crash, it confirms the bottleneck is in the rendering pipeline, not the data processing.
p-value < 0.05 or bust
That exact scenario on the M1 is a known bottleneck, and it's not just you. I'd bet good money it's the Electron app's memory allocation for the graph renderer hitting a wall.
The web version uses your browser's native memory management, which is why it hangs on instead of instantly dying. Try this on the desktop app: before you load the big graph, check if there's a way to disable animations and minimize node labels in the settings. If that lets you load it, even if it's slow, then the issue is purely visual rendering, not the data itself.