How often have you been sat glaring at a screen having just filled out a form and all you can focus on is the spinner in the browser tab, just endlessly spinning away? If you suspect your internet connection isn’t to blame, there is a high chance that the code isn’t up to scratch.
While the complexity of code is very much behind the scenes, what it affects, chiefly a site’s efficiency, couldn’t be more centre stage. If you’re met with long loading times and delays, you’re more than likely putting up with the end result of inefficient code. But what does this look like and what can you do to fix it?
In this instance, code complexity doesn’t mean how complicated a language is to learn or understand. It refers to the amount of pre and post processing required to display information to a user or to deal with their input. One of the main contributors to complexity in back-end web programming is looping through data.
When you look at your previous orders on Amazon, your items in a shopping basket with Tesco or any form of data that is dynamic and updates through time, there will likely be code at the back-end that loops through and prints each item to the screen sequentially.
Increasing complexity generally means decreasing efficiency
One loop is fine and generally unnoticeable to a user. If there are 10 items, it would take more time to loop these through. But what happens if you have a loop inside a loop? This is known as a nested loop.
With other loops inside them, those 10 items now have a complexity of 100 - 10 loops, with 10 sub-loops in each. In the case of a third nested loop, the complexity now becomes 1000 - 10 loops, with 10 sub-loops and 10 more sub-loops in each of those. The amount of processing required goes up exponentially for every additional loop. Just writing this out is complicated!
Let’s say you just did a skydive with your mates. You all survived and decide to store that memory on your Facebook wall as a status. You add your location, tag the guys you’re with, find a feeling that matches how you’re currently feeling (sick, excited, dizzy…) and you press post.
At that moment, all the data you just set up is sent through the code backstage. Your status will be stored in their monstrous database against your account. Your visit to the location is stored in the database too. The status you posted would also be stored in the database as a link between you and your friends, so that their timelines also show the status. The feeling you chose will also be stored in. There are at least 4 transactions between your account and the database when you post a status like this, but there are probably many more.
Before writing all of this information to the database however, validation checks ensure you wrote in the status box and were logged in with a valid account. Before this even happens, a list of users that only includes your Facebook friends will be retrieved from the database. The complexity of what goes on behind the scenes goes up and up.
From what I’ve seen and written, I do three main things to write efficient code:
Re-using Code
If you’re developing a website with a complex registration form on multiple pages, you could find yourself rewriting the same code for different places. But why?
Doing this means that the logic could vary slightly for what will essentially be the same form in two places. Another downside is that you now have two places to update the code if there should ever be a change. But worst of all, you’ve also just created an extra place for a bug to settle.
Instead of retracing your steps, put any common code in one centralised place and call this central location from any page that needs to. This saves a bunch of coding, improves website efficiency and limits the chances of unnecessary bugs. It’s a winner all round.
Limiting the use of nested loops
I’m not saying never do it, as there will be some cases where it is unavoidable, but if you find yourself in the 4th, 5th or 6th level of a loop, it might be worth asking yourself if there’s a better way. More often than not, you’ll be able to split complex logic out. It may mean spreading it out across more loops, but at a lesser, more efficient depth.
It’s worth looking for a solution even if a complex website with this number of nested loops works for you, as that is no guarantee that it won’t crash for someone else.
Interactions with the database
It will always be better to read from and write to the database as few times as possible. It takes time to send or request data from a database and while additional calls to your database won’t stop your website, numerous extra calls will reduce its efficiency.
Similarly though, selecting all of the data from your database so you don’t have to make a second call is just as bad. If a user logs in with a username and password to a system where there are 4,000 other registered users, bringing back the entire 4,000 rows of data just to check one login is serious overkill.
Instead, it’s much more effective to bring back just the rows that match the username that the user entered. Then the check of the users’ password can be checked against just the 1 matching row, not the data in its entirety. Pulling all the data is a sure fire way of slowing down an application.
If you need to make lots of calls to the database for various bits of data, it is almost always better to keep the connection to the database open, rather than opening and closing it every time. This is comparable to manually turning a car off every time you stop, only to start it again when the engine is needed. It will slow you right up and is more likely to cause damage.
Code complexity is generally not something a user will notice, especially if it is done right. But if you ever find yourself browser watching while a web page tries to load, you might well be another victim of inefficient code.
