Decreasing Database Runtime

By Michael Sidenstick, Programmer/Developer

While learning the fundamentals of good programming principles in college, one of the most important lessons I was taught was on the topic of code runtime. If you’ve ever been frustrated by websites loading slowly or software taking forever to load, you already know why decreasing code runtime is so important– no one wants to sit for a minute waiting for some software to finish running. This past semester at college, I had a digital logic class where we designed logic circuits and running just one simulation would take three or four minutes. Decreasing the load time and runtime of programs can increase efficiency and reduce frustration drastically.

So, when it comes to Ninox, what makes programs run longer, and how can we make our databases run more efficiently? Let’s consider the lowest unit of runtime a calculation; if we write a formula that performs the calculation 7 + 11, this is considered one ‘operation’. The number of operations a program performs is what determines the runtime– programs running hundreds of operations will take far longer than a program with only a few. Some functions or chunks of code have greater runtimes based on the fields they update, or on the complexity of the task they are accomplishing. The cost of each line isn’t easily determined in Ninox, because writing a line such as “x := 5000” perform assignment, which Ninox handles in an unknown way in the backend, and each native Ninox function has a different unknown runtime as well.

To understand how to optimize your programs, you first must understand where the problem is coming from. One large source of slowdowns comes from code written to work correctly, but not to work efficiently. Functions with large amounts of lines that haven’t been organized often contain unnecessary lines that slow down the system and reduce readability. Additionally, different solutions to the same problem can often run at very different speeds. If you wrote a button that cleared a record upon being pressed, if there were many fields to be cleared, each clearing could take something like 10 or 15 seconds. However, alternate solutions could be tested that may run faster; for instance, instead of clearing every field in a record, just delete the record and create a new one at the same time to ‘clear’ the fields.

If you have a database running slowly, the best course of action is to first diagnose where the slowdowns are coming from, and then to troubleshoot potential solutions by cutting down on unnecessary code, searching for alternate solutions, or tackling the problem in a different way.

en_USEN