10 Mindsets of the Optimizing Approach

HyperConnezion Performance Series #2


This is the first part in a series of articles to bring you on a fast path to success

As an end user sometimes life is very difficult. The only thing we can do is blame the software developer or the server provider. It is beyond our hands. There is very little we can do — so we think. Everything is in our hands. We can provide feedback, we can configure the service, we can decide on the deployment method and the providers we use. Be proactive and make a difference!

Performance optimization is a mindset. It is an attitude. It is a lifestyle choice. Remember this, if you see someone coding without paying attention to it, but at the same time, delivering the required work, then it is unoptimized code.

Optimization is something everyone knows but also something no one does. It’s great if you already know every point below. It’s even better if you actually take action on it!

1. Make it faster

Gone are the times when we can get faster and faster CPUs. Parallelism is the new key to succeed. It is far easier to add more CPUs where required. Multi-threaded code is ever more important. Dead locks need to be reduced to a minimum. Consider lock-free data structures and algorithms. Choose non-blocking web servers.

2. Big O Notation is often impractical

This is often impractical especially in today’s world. What is the real life performance figure? Whether it’s considered constant time, logarithmic time or whatever it may be — the important thing is the end result on common data sets you’ll be using. Computers are a lot more complicated than before — cache misses, multi-threading and all sorts of reasons can completely change how an implementation does not match theory. How many users of the algorithm do you need before we even reach a break even point?

3. Experience performance for yourself

This is at least what we spend the most time on. We defer loading of resources like JavaScript and CSS where possible so the user sees a response first. They can wait but they want some feedback. It is about the user interaction. At the end of the day, performance optimization is about reducing downtime (e.g. when server overloads), improving user experience (e.g. less rage waiting for a website to load) and to save time. Think about the end goals and what it means to optimize rather than to just do it. Don’t just develop the code. Don’t just deploy the application. Many engineers have never used their own application. Try it for yourself in the shoes of an end user to get an actual feel of where the issues really are. Don’t wait for someone else to report it.

4. Identify the bottlenecks earlier

In later stages of any development lifecycle we often do profiling to identify bottlenecks. Why can’t we do this earlier? As an experienced developer and system administrator (now devops) we can often predict where the bottlenecks will be. Which part of the application takes the most time? Let’s optimize those. We can and should already be able to tell whilst writing test cases (as part of development best practices). Don’t ignore it. If you know it’s slow bring it up. It might not matter because the managers just want to get the features out the door but it’ll always bite you back later.

5. Horizontal scaling is an easier and more effective solution

Does the application scale? Horizontal scaling is now an important aspect of any applications. We’re in a cloud era. Adding resources on demand is now a very easy solution. The problem is how can this be done and how effective it is. It is easy to add frontend load balancers and other external devices to create a solution but if your application doesn’t scale then it is all moot. Where are the bottlenecks and are there single points of contention? E.g. would a save ultimately mean we’re waiting for a database lock that never gets released if actions are done in parallel?

6. Performance as a Key Metric

Include performance testing as part of the design and plan. Performance should be a key metric and something to be signed off on. When designing the architecture of any project — make sure to ask and get accurate numbers on the number of users, including unexpected possible spikes. Look at other websites or applications for references. Break it down into key metrics, e.g. how long it takes to save a blog post in the new blogger platform. Compare these targets as you go. Reject any code committed that doesn’t pass performance testing as part of continuous deployment strategies.

7. It is a long journey

Plan for the future. Look at the bigger picture. How often have you implemented a feature without considering the bigger picture? It might take you all of five minutes to add something to an existing codebase or to deploy an open source solution that fits the bill. Add another five minutes to do it properly. Don’t make something else cleanup for you.

8. Keep searching for a faster way

People are often lazy. We’re doing things the way we do it because we’re accustomed to it. However, there may be better ways. Keep improving! Reach out. Keep an eye out for the world. Maybe there’s been a library released, a new code pattern or anything. Don’t stick with what you’ve been using for the last few years because it’s the easy way out.

9. Features are no longer the selling point

An unfortunate business decision is always to release early and update later. Leave features for the next version so more people will buy it. In a world fully of services (the software as a service model), we pay for a subscription (on a constant basis). You no longer need to hold back. People will continue paying and can only continue paying. They cannot download and stick to the old version because the updates aren’t attractive. We live in a new world of a different model and mindset. Consider the change.

10. Make testing a habit

Think agile. Profiling doesn’t have to be cumbersome. Include as a routine when testing new functionality. Check out the performance whilst making sure a future works. Are there any quick fixes you can do? If not, report it and make sure it’s noted for future development at the very least. Keep it in scope. Make it a habit of keeping performance in mind.

Stay Tuned

Hyperconnezion Performance Series is here to correct the myths around performance and how to get it right. In the next series of articles we will discuss the various strategies to ensuring the site is performant when needed — not after the fact.

###

【About the author】

Harry Chen, the founder of HyperConnezion, was born in Hong Kong and raised and educated in Sydney, Australia. Have nearly 5.5 years in managing IT startup, and 6 years experience as a developer, consultant, and system administrator.

【About HyperConnezion】

HyperConnezion is a cloud and managed services provider. Our focus is tailor-made, custom solutions in Asia Pacific. We cater to individuals, small businesses and all the way to large enterprises that need simply the best. No matter the complexity or scale, we’re here as your IT companion to guide you through any hardships in technology. Follow us on:

Official website: https://hyperconnezion.com/

Facebook: https://www.facebook.com/hyperconnezion/

Twitter: https://twitter.com/HyperConnezion

LinkedIn: https://www.linkedin.com/company/hyperconnezion

Instagram: https://www.instagram.com/hyperconnezion

Show your support

Clapping shows how much you appreciated HyperConnezion’s story.