Much as I love fibery (and I really do: it’s awesome!) I’ve found that I’m falling further and further behind in using my (project tracking) app because it’s been getting slower and slower to render the UI: currently I can expect to wait 60 seconds or more for a single entity page to complete rendering: and when I try to interact with the app before it’s finished rendering I end up with incomplete syncs resulting in missing rich text and “restore backup” prompts. I’ve been noticing the rendering speed decreasing steadily over time: presumably either as a result of the increasing size of the databases (eg. something like 700 “task” entities currently) or the increasing complexity (more and more relations, formulae, etc.), or possibly both. I’m using a 2014 Mac Mini (dual core) and a 2015 Macbook Pro, both perfectly responsive under normal usage (no discernable lag in browsing twitter, github, etc.) but my fibery app is now horribly slow (in Chrome, Safari, Firefox and Opera). I’m pretty much at the point where I can’t justify continuing to use the app, because I find myself unwilling to create new tasks and interact with them because I know it will involve so much waiting for UI elements to render each time I switch entities. I would very happily pay for increased performance, however: if there was (eg) some way to offload the CPU/memory intensive rendering tasks to the server, and that was a paid feature, I’d grab it like a shot! Do I have any options? I’m really loathe to abandon my app because it’s perfect for my needs, other than the performance: I can’t imagine how I could reproduce even 50% of its functionality in another service, or even spread across multiple services, so I don’t have any feasible alternatives: and I can’t justifying spending $1000s on a faster machine just to be able to use one web app. Honestly: this is the one issue that’s been keeping me from becoming a paid user: really hoping there’s some solution!
I should probably add: this performance issue has also prevented me from publishing this app for all my colleagues to use: that was my original intention in developing it: to deploy it as a corporate service (for approx 10-12 colleagues). But we all have older computers and I can’t take the heat for pushing this out to the company while it’s so (increasingly) painful to use.
I for one (and I’m sure I’m not alone) am very interested to know how this evolves.
How well Fibery will scale with larger and more-complex data is a major concern for me, because nobody wants to marry themselves (and their company) to a complex entreprise-critical system that could slowly become less and less workable over time…
Yes, I’m also watching with interest. I am not experiencing these performance issues yet (in fact I was just appreciating how Fibery is actually faster for me than local app Obsidian at initial load and opening of a given, specific object/page/entity). But I don’t have a ton of data or relationships or formulae, etc. in this workspace yet!
I will in due course post some learnings from the investigations I am doing with @masp but I can say already that Fibery has some customers with 100’s of thousands of entities in their workspaces that are not experiencing slowness, so we should be able to reassure people that Fibery can scale without becoming unusable
Thanks Chris for a fairly exhaustive analysis: as I suspected, my performance issues seem to arise mainly because I have a lot (like 10s) of many:many and 1:many automatically derived and populated relations between my various databases (and lost of formulae deriving metrics from them). It had not occurred to me that these relations can all now be hidden (so they don’t render) on the entity page: Chris pointed that out and I’ve hidden all but the 3 relations I really need to interact with manually: as a result the pages are rendering a LOT faster. I haven’t had time to really benchmark the before-vs-after performance, but it seems like a huge improvement. It’s still slower than I would like: but I do typically put a lot of entity references in my rich text fields: those can still take several seconds to render: but that’s a lot better than before, when I was sometimes waiting more than 60 seconds for a single entity render to complete! Quite a relief!
I too get performance issues, in particular when trying to run a meeting in Fibery and clicking around an array of connected db’s and entities. Slows down the meeting which is detrimental, but there are other benefits of Fibery that make it the best app I’ve ever used for running a meeting! Still, would like to see how this is addressed as the slowness is a concern when I start to access more data quickly…
