Like the concept, but performance is a showstopper

I’m new to coda, but I really liked the concepts (tables vs. cells, views, etc), so I tried it out over the weekend. I found the resulting usability quite good, especially around column formulas with autocomplete.

But performance is a complete showstopper for me. I loaded up a medium-sized table of stock quotes: 1200 rows, 3 columns. I created a separate table view, with extra computed columns to drive some charts, tried pivoting the data by grouping columns to left/top.

Performance slowed down to a point where my document can not even be loaded anymore :frowning:

I’ll share the doc if that can help identify the cause of the issue.

3 Likes

Indeed this has been discussed in a number of Topics here.

Coda staff say they are aware and are working to improve performance. Remember it is still a beta right now, as advanced as it is.

1 Like

Hey @Olivier thanks for your feedback and sorry about the slow response. We’re actively working on improving the performance of big docs and would love to take a look at your doc as we prioritize our fixes.

Since your doc is in only 1200 rows and 3 columns, it’s probably some other issue since things usually don’t slow down at that size. If you can share the doc with support@coda.io, I should be able to help you make some small optimizations to get it to work more smoothly. Would appreciate if you can also message us on Intercom and mention me. Thanks!

Hi Angad,

I’ve shared the document as requested. I’ve given you edit permissions as I don’t intend to further work on it at this point.

Any chance you can share the document publicly, here on the thread?

Yeah, it’s the grouping. I don’t think there’s anything can be done to work around that problem.

Hopefully, the devs can do something about that soon.

2 Likes

I’m also finding grouping to be very slow. Would appreciate any update from the devs on efforts to speed this up.

One thing I noted is that when I press the button to add a new group, Coda is trying to create a new group based on its selection of a default grouping before it asks me which column I want to group by. When the default is not the one I want, Coda is doing a lot of unnecessary work to create the default grouping that I will not be using.

2 Likes

Would like to throw my vote to prioritizing performance. Right now, performance is my biggest pain point in Coda - it adds considerable friction to routine tasks and has made me seriously consider moving to regular spreadsheets (or Notion). This applies to Coda on every device, though it’s especially irritating on mobile (both iPhone and Android).

E.g. if I want to add a task to my task management system, I need to open the Coda app, press login (every time), it crashes (every time), then I reopen the app to reach my Coda homepage after 5ish seconds of loading. I then click my task management doc and wait another 10 seconds for it to load, then the specific page I need (+5 seconds), then the plus button to add a row (+5 seconds), then it’s on to laggy text input. Besides the auth issue (Android only), the experience is mirrored on both my iPhone XR & OnePlus 3.

I’ve gone as far as to create multiple Google/Typeforms purely for personal use w/Zapier so I can avoid inputting data into Coda on my phone.

I really love Coda and want to see it succeed as a product & company, but I’m using it too actively to overlook this kinda thing forever. I’ve heard similar sentiments from some other Coda users I know. Are any big performance improvements on the horizon, especially mobile?

(I’m happy to share my docs & discuss what I can do on my end to improve performance, but this performance thing is an issue even with low volume docs (fewer than 200 rows), though it certainly gets worse as complexity rises (I have some docs with 100+ sections & low individual complexity))

5 Likes

@Samuel_Stowers would you explain how you’re using 100+ sections? I’m interested by this use case.

@Samuel_Stowers thanks for your post. Can you describe the type of data you have in this workspace, specifically the documents where you are waiting to load and edit rows in? For example # of rows and columns in the specific table you are editing, perhaps even the column types (are they lookups in other tables, formula heavy, etc)?

It’d be great to know if this is something that would affect typical users eventually or is something unusual to your requirements.

Well I loaded up a doc to 1000 rows but I hit my free user limits. Performance at this volume is acceptable on Chrome/Windows, but I’m not really able to get a sense yet on when/if it starts falling flat in my use cases.

Would be great to hear from Coda on whether you can promise to support the volumes needed for teams of 5, 10, 20 developers for project management + knowledge store purposes.

@Johg_Ananda I was creating a fully functional prototype of my insomnia treatment app! So each section was a screen, with buttons/links for navigation & tables for databases. I don’t think it’s a typical use case but it worked pretty well, with the exception of the authentication & performance problems.

@Ed_Liveikis Sure. For my personal management doc, my todo list table has a bit less than 200 rows right now and 19 columns. There’s a decent number of formula columns, but none are especially complicated.

One thing that might be causing performance problems is that each task automatically counts how many pomodoros worth of time were spent on it. This way I can track how much time a given task takes, how accurate my prediction was, and even how many minutes it took (estimated). That lookup might be inefficient, but I think the connection is valuable.

Re: waiting time, large operations are even slower. For instance, on my weekly review screen, I’ve got a button that marks all incomplete tasks as “Missed” for the week. I just now pressed it and it froze the tab for 45 seconds or so (moving through this 200 row table). There’s usually a 1-4 second delay between when I click the button to add a new task (row) and when I can type in it.

1 Like

@Samuel_Stowers ok so you made each section a view of the app, like an ‘live’ wireframe? And used Coda tables to get the functioning … like an MVP that you’ll pass to another dev team to make into a mobile app?

Well, dev team being me, but that’s the idea. :slight_smile:

@Samuel_Stowers although 19 columns seems like a lot for a todo list, still 200 rows is very little. Perhaps you could narrow down by removing formulas (and saving them somewhere) or other features, to see if you can find the culprit?

We’ve announced additional improvements to performance, especially for docs with tables in them: Update: Our continued commitment to performance

1 Like