The performance of your application is important to your customer. As stated previously, the performance your application is as dependent on the knowledge and skills of the programmer as they are on the language used to create it.
This excerpt from the book “SQL FOR .NET PROGRAMMERS” by D. M. Bush serves as another example where the programmer’s skills created a problem that could have been avoided if performance was a key consideration:
They decided to be clever and created a name/value pair system instead of putting it all in one row. It should be no surprise to anyone that once this went into production it couldn’t hold up in real day-to-day use.
… They obviously had a problem.
But this could have been avoided if performance had been part of the criteria. As the programmer I was discussing this with said, “All they would have had to do is throw in a million fake ‘rows’ and they would have known right away they had a problem before they built out the rest of the system.”
I’m not saying you need to optimize the guts out of a system, but anything that takes more than a few seconds to return a couple thousand rows, definitely has an issue.
Working and Performing are NOT equal
An application that works is not necessarily an application that performs. As suggested in the excerpt, the root of the performance problem began with the scope of the application itself: Performance was NOT part of the design criteria. I contend that this is simply an excuse and not the root cause.
A skilled programmer should have sufficient knowledge to understand when and where code optimization and subsequent performance testing is required. From the excerpt above, the performance impediment is directly assignable to the initial design and the lack of a test plan.
A DVP&R (Design Verification Plan & Report) is one of many tools used to develop new products and materials in the automotive industry. A skilled programmer understands that unit testing is critical component of application development.
Many programmers take advantage of performance monitoring tools when testing their code. If you have the opportunity to write T-SQL queries using Microsoft’s SQL Server Management studio, you will appreciate using the various performance monitoring tools available and query execution plan.
Not surprisingly, performance tuning and optimization efforts should focus on code where processes or functions are subject to repeated execution. Consider that SQL is typical used to work with thousands or millions of records at a given time. Fractions of a second on each iteration can quickly add up to minutes or hours of “wait” time.
I often say, “Be careful who teaches you.” Many tutorials and books can show you “how” to write code that works. However, I prefer those that also explain “why” and suggest methods for improving or enhancing performance.
For example, section 5 of the book Learning Python by Fabrizio Romano (Packt Publishing Ltd) is devoted to saving time and resources and echoes the sentiments expressed here. Certainly, some books are entirely devoted to improving and optimizing performance.
The code we use to perform a given task is critical to the performance of the application. Various algorithms exist to perform a variety of tasks where some will perform better than others depending on the circumstances. By way of example, consider an application that continually requires a large number of elements to be sorted. A programmer who understands the application will implement the best sorting algorithm from the many that are available.
Programmers solve problems! Just for fun, consider the 2 Eggs Dropping problem as presented at “ProgrammerInterview.com“. Although the solution is presented, it is interesting to note the variety of responses to this same problem on “Quora’s Dropping Eggs Q&A page“. You have a first hand opportunity to see how different people approach the same problem to arrive at a solution.
DRY is Lean
DRY, an acronym for “Don’t Repeat Yourself”, is a programming principle that is easily applied to writing code effectively. It is certainly easier to optimize a function or procedure that is written once and used in many places. Libraries or packages make it easy to update a single piece of code that can be deployed across multiple applications.
There was a time …
Programmers once took pride in writing fast code that was “tight” and required the minimum resources to execute successfully. When I started programming in the early 1980’s, machines were considerably slower with extremely limited memory and storage.
The concern today is that many “programmers” are simply using “building blocks” of code written by others without really make an attempt to understand what is happening behind the scenes. As a result, resource hungry applications are created where poor code is masked by faster multicore processors and seemingly unlimited memory and storage.
The applications may have a great look and feel, but if the performance is lacking so will customer satisfaction. The references here suggest that programmers are intuitively inclined to find the “best” fit, high performance algorithm. That “performance” criteria needs to be defined seems counter-intuitive to the best practices of a good programmer.
Until Next Time – STAY lean!
2 Eggs Dropping – ProgrammerInterview.com
2 Eggs Dropping – Quora Question / Answer Forum
SQL For .Net Programers by D.M. Bush – Version 2.0 (Second Edition), Text copyright 2013-2016, DMB Consulting, LLC, ISBN: 1533071128, ISBN-13: 978-1533071125.
Design Verification Plan & Report (DVP&R) Services – Intertek.com
Learning Python by Fabrizio Romano, Packt Publishing Ltd., ISBN 978-1-78355-171-2
Vital Introduction to Machine learning with Python: Best Practices to Improve and Optimize Machine Learning Systems and Algorithms (Computer Coding).