Optimizing Software
From Zanecorpwiki
Reduce the Need to Optimize
Write with IO in mind.
IO will be for many more important than algorithmic optimization. Minimize:
#bad foreach (i in set) do runQuery(i); done;
#good foreach (i in set) do updatePredicate(i); done; runBulkQuery();
Remember to consider space and time, and how they relate.
Memory impacts time. If you need to remember something about lots of things, don't store giant blobs of data in memory when all you need is a few bits of information.
#bad
object_array;
function find() { foreach (object in object_array) do return object if object.field = 100; done; }
#good
index_array;
function find() { foreach (id in index_array) do return findObject(id) if id = 100; done; }
Refactor data structures/natural data expression.
I haven't, nor am I going to mention algorithms and big-O. That stuff is important, but for most developers, even cutting edge developers, that's not the problem. I've found that in most of my work, when I end up with an inefficient process, it's because the data structure is pushing me towards it. In almost every case, this means that my data model fails to reflect something about the external reality I'm modeling. Fixing the data structure (which usually means database tables or something similar) usually makes for faster processes and a more natural model.
#sub-optimal <category id="99" name="root" /> <category id="100" parent="99" name="stuff" />
#optimal <category id="99" name="root"> <category id="100" name="stuff" /> </category>
Of course, there are cases where the first example is perhaps preferable than the first. Even in the same application you may want both views. Sometimes it's a question of level. Yet, it's easy to see how displaying a category tree is made much simpler by the second. So is finding the children of a category. The hierarchy is natural to the data, so if possible, express it in that way.
