In this article
FAQ’s
What does “calculations have been temporarily disabled” mean?
Things can be deleted or added and edits can be made, but Coda will not calculate the results of formulas. If a formula is changed for a column, the values in that column will not be updated to the new results until calculations are turned back on.
If I delete things from my doc with calculations disabled, will those deletions actually happen?
Yes, you can downsize your doc by deleting old rows, unused columns, and even remove things like conditional formatting. These deletions will all take place and help to downsize the doc to a level where calculations can be reenabled.
How do I get calculations turned back on?
There needs to be a significant enough decrease in the doc’s size to allow for calculations to catch up once they are turned back on. If you feel you have removed a good bit of rows, columns, and/or conditional formatting, please reach out to support and include the link to your doc.
Introduction
When we talk about performance we’re usually referring to two separate but tightly connected things, Size and Speed. Each one affects the other and you’ll see that we discuss them both separately as well as together. There are no 100% answers when trying to optimize the two and there will always be a compromise on both sides.
A good metaphor is packing for a camping trip. The more gear you pack, the more comfortable you’ll be while camping, but this adds weight and means you will hike slower. The less gear you pack, the faster and farther you go, but you'll be a little less comfortable while camping. There is, and always will be, a trade off so the goal of this article is to provide the info you need to best assess your situation and preferences in order to provide the best solution.
Doc size refers to how much storage space a doc uses and is measured in megabytes (MB). This refers specifically to the size the doc takes up on our servers. We currently show this as a percentage of the limit in the doc warning you will see if your doc is approaching that limit.
So why does this matter?
The full doc is downloaded into your browser cache so that you can work in it even without an internet connection. But the bigger the doc size, the tougher it is for your browser to run it. If the doc grows big enough, it may become too big for your browser to load at all. This is why calculations might be turned off and why downsizing the doc is a good idea. We want to catch things before it’s too late.
Size Ranges
Where to start downsizing
Rows
The more columns you have in a table, the more space each row will take up. We have seen docs that run just fine with 100,000 rows and others that have trouble at 10,000 rows. It depends on your particular doc setup as to how many rows you can remove to bring the doc size down enough. As a ballpark starting point, you can use the percentage of your doc size as an indicator. If you have a 10,000 row table and you are at 99%, you will want to try removing 2,000 rows if your target is to get down to 80%.
After removing rows to bring your doc back down to a workable size, see row archiving as a strategy as one option to keep the doc size down moving forward.
Relations
If you have a relation column that returns many row values per cell, it’s possible that this is taking up a lot of space in your overall doc size. Relations are a powerful feature in Coda, but when used to an extreme and returning 100’s of values per row, they can cause the column size to grow fairly large. Removing columns like this or finding a different strategy can help both speed and size performance in the overall doc. See this doc on building best practices for more detail.
Row archiving as a strategy moving forward
We’ve discussed the size differences in various column types and have seen that more complex types take up a good bit more space. Another truism is that more columns take up more space than less columns. The two bits of information can help us develop possible archiving solutions that can save space while retaining relevant data for the customer to reference.
Bigger docs tend to have tables with many columns. This is very useful when you’re needing to filter and compile data based on the individual data points in those columns. But after a project is done, this can be overkill for most situations. You’re likely looking to maintain a summary of a project and maybe a data point or two for reference.
Let’s say you have a project table with 100 columns of various data points. When that project is marked as complete, maybe you only need to know the summary, the date, a customer sentiment rating, and the project lead. This gives us 5 columns if we include the project title as it’s own column.
In the summary column of this new archive table, we can include the items from the other original columns, but stored as text instead of separate data points. With some creativity using Concatenate() or Format() you can create all sorts of summary write up styles that combine everything into one text field, so not really any data loss, simply sacrificing some rarely used filtering capabilities on individual columns for a big savings in storage size.
So in the end we can bring that 100 column table that is monstrous to look at down to 5 simple, targeted, and very easy to grok columns. This is both beneficial for the doc as well as the customer. One of Coda’s biggest strengths in offering the functionality and layout options that it does, is allowing you to clear away the clutter and whittle your data down to the few items that require the most focus and the most benefit.