Options Table & Speed Suggestion (future development)

After reading the post Top 10 Most Common Coding Mistakes in WordPress Plugins the other day, and combined with some recent discussions of Atahualpa's speed, something jumped out at me. While the article is targeted at plugins, there's not that much distance between plugins and themes.

One of the gripes in the article is plugins that add many new rows to the options table; the suggested solution is to put only a small number of rows in and combine multiple items into a single row. I'm torn on the merits of that because it comes down to the question of which is better: reading multiple rows or decoding multiple values out of a single result in code.

However, the thing that struck me is that with some of the complaints about Atahaulpa's speed it might make sense to generate most of the "static" CSS as a single big block when options are being saved - that way when the theme is reading from the database during regular use it's only pulling a small number of values - the big CSS block and anything that is dynamically generated (differences if you're logged in or not, browser-related changes, etc.) if anything. In this case we don't have to worry about the query-vs-decode issue because the decoding is all happening anyway on the client side - the only question is whether the content to be decoded (the CSS) is generated on the fly when the page is requested or if it's generated as a static block only when the configuration is changed.

Of course, it's possible that this is already happening and I missed it, but if not then it may be something worth looking at.

Similarly, if the way options are saved was consolidated into a smaller number of rows, each such row would also have to have a version number on it to avoid confusion during upgrades, etc. If adding such a thing, it might make sense to add both a version number and a name - thus allowing the saving of multiple Atahualpa configurations.

Just a couple of thoughts.