I’m on a bit of a crossroad right now, so before I do anything drastic (i.e. split up tables into smaller ones) I’m hoping to get some input on what’s best performance-wise.
Right now I have a master table with 40-50 columns. I think about 1/3 requires simple number input and the rest either performs pretty basic lookups or calculations. Specifically, I’m wondering the following:
Say you have a column with formula “X*Y + X”, where X is a value that you get from filtering another table. Given that there are 2 instances of X, the filter request has to be executed twice per row. Therefore, I figured it would be more efficient to lookup X in a separate column and then refer to this new column in my formula (thereby saving 1 filter request). However, this assumes that minimizing these kinds of requests is more efficient than minimizing columns. Thoughts on this?
How much performance impact do rows with a lot of empty columns (with and without formulae) have?
Does hiding columns from view decrease their impact?
And this probably only the Coda staff knows, might some of these concerns become trivial in the somewhat near-future because of architectural improvements?
Looking forward to hearing any thoughts and experiences regarding these matters.
I found out today that if I replaced all formulae of the form…
AND(expr1,expr2)
…with…
expr1 && expr2
…it completely solved the severe performance problem I was experiencing.
Prior to the change it would take 41 seconds to enter a value into a field. (It would carry on showing the old value and I’d see the message “Calculating”. 41 seconds later the value I entered would finally appear.)
After the change the new value appears in just over a second. It totally turns things around and makes an unusable application usable.
We’d benefit greatly from a reference page on tips like that. Maybe use this thread as input from users then bundle them into a help page?
I guess the question would be repeatability of the results. I.e., in Nick’s case it’s not obvious why changing syntax would make that much difference, maybe the fact his project has multiple grouped and aggregate views?
I’ve also reproduced this on a much simpler application with just 3 tables and no groups. In the simpler example it reduced data entry time from around 4 seconds to nothing.
One year on… does such a list with things like this exist? I’m in a situation where my doc has become quite slow, and I’m slowly trying to figure out why…
I’m wondering about column count and performance. There are many times I find myself wanting to store buttons or calculations in extra columns as they can be easily triggered or referenced from other formulas, creating sort of a programming interface on the row by being able to read properties (numbers, lists, etc), or activate functions (buttons) on the row as an entity.
Has anyone noticed with downsides to this approach in regards to performance? Thanks!
In terms of performances, it’s generally better to divide a big formula you would use in a single column into smaller ones used in x numbers of columns .
At least, this is generally a way to optimize a slow doc…
Same goes with buttons … instead of using a single button to do a lot of things on certain conditions, it can be better to create a “workflow” within a row, using multiple buttons running one action and then push another button … etc…
But of course, as always, it depends on your doc, its goal and your needs .
Just to give you some sort of references for the number of columns in a table, I generally get close to a “working” one (doing what I want) when I’m between 30 to 45 columns. After that, I might need to add some more just for the “display” .
This is obviously not always the case but 30 to 45 columns seems to be some sort of “constant” in the way I build my docs
@Paul_Danyliuk might potentially have more precise info regarding your question though
Thank you! Yes actually I’ve been drifting up towards 45 columns or so as well in my more full featured docs. I’ll report here if I notice any performance problems.
Everything is super case-by-case but generally speaking you are right.
From my experience it’s better to care about good data design first and worry about performance later. Usually the latter will be a byproduct of the former.
From my experience it’s better to care about good data design first and worry about performance later. Usually the latter will be a byproduct of the former.
So true! Overall with the performance improvements over the past year, my docs are performing very well and I’m very happy that Coda made performance a priority.
.