About us

Mapusoft Technologies is the leading provider of porting and abstraction solutions that increase the
level of code re-use to protect software investment.

Copyright © 2017 MapuSoft Techologies, Inc. All rights reserved.

Code size versus execution speed – This is the classic tradeoff and the one that most embedded engineers are familiar with. I’m not going to go into much detail here because it’s covered in so many other places. If you’ve been in the embedded software world for any length of time, you’re already familiar with this issue.

Module optimization versus application performance – There’s a tendency for many programmers to try and make their code run as fast as possible. However, if only one module is performing at its peak, there are often unexpected consequences for the entire application.

Function speed versus “understandability” – Ok, I made that word up. But most of you will get it. Rather than writing your functions for lightning fast speed, try writing them in a way that your teammates and future programmers can understand them. A software function shouldn’t need 3 hours of study time to understand its functionality.

Long-term maintenance versus Hitting your schedule - This is not a code optimization technique per se, but it is still relevant. Most software projects are on tight deadlines. As the deadline approaches, you might be tempted to cut back on commenting and explaining what your code is doing. Resist that urge. You will save yourself time in the future. Yes, it will take you a few hours longer, but you will save yourself lots of headaches and grey hairs when you have to come back to your code and update it.

I hear so many folks misunderstanding these core concepts that I often go back to discussing the fundamentals of the optimization process. For some reason, embedded software developers get so obsessive on optimization that they lose sight of the big picture.

Here are the fundamental steps any engineer can use to go through a successful optimization process.

Number One: Determine Your Goals.

How to Optimize like a Pro

I just heard a story about this guy carpeting his office with remnants (carpet remnants are the leftover pieces from the huge carpet rolls). He went through all types of sizes and cuts, but none of them fit the room perfectly. He spent almost 2 weeks trying to make those pieces fit. Whenever he found a piece that was square with one corner of the room, the carpet would just pop up in another. No matter which piece he used or how clever he tried to be, none of the pieces fit perfectly.

Why am I telling you this? Because this story is the perfect analogy for the optimization of embedded software. No matter how much you try to nail down (optimize) one section of your application, it will always pop up in another corner.

Embedded software and embedded platforms are all about optimization. These devices are known for their limitations – either memory or storage space or processor speed – and it’s the engineer’s job to make the embedded software application run at its highest performance level. That’s optimization. It’s one of the most talked about topics among embedded engineers yet the concept of optimization is one of the most elusive and complicated concepts to understand and to teach.

So what does this have to do with carpeting an office?

Well…when you are optimizing your code, you can spend hours making one section of the application perform optimally, but it always pops up in some other corner. Just like the carpet.

In other words, optimization of embedded software is full of trade-offs.

Here are a few:

Do you want your application to fit into less memory? Do you want to take up less Flash memory? Are you looking for it to run faster? Are you looking for it to be stable for future updates? All of those things are important and you must decide ahead of time what you’re goal is. Why? If you don’t determine your goals you’ll spend countless hours in meetings debating the various aspects of your optimization.

By the way, if you said ‘yes’ to all of the above, then you’ve missed the entire point so far. Optimization is about tradeoffs.

Number Two: Get a baseline results.

Before you start your optimization efforts you should understand your current performance level. That is easily done by getting a snapshot of your current application. There are profiling tools available that provide visual interfaces for gauging your application's performance. Use these tools to gain a baseline run of your application.

Number Three: Pick one (and only one!) modification to make

Look for trouble spots, bottlenecks, or other red flags that don’t match your outcome goals. Only work on one area at a time. Make those changes to your code and then check your results against your outcome goals. Why make only one change at a time? If you inadvertently break something, you want to be able to revert back to your last known stable configuration.

Number Four: Compare your new results

Rerun your profiler and your test software and compare it to your previous outcome goals.

Number Five: Repeat until done

Repeat all of these steps until you have a finely-tuned piece of software.

Now, here’s what is going to happen. Many of you are going to take short-cuts. In fact, most of you are going to ignore Step Number 4. Resist that urge.

Pick only one thing to optimize at a time. If you don’t you’re going to have unknown and weird interactions that you won’t be able to find. Test one thing at one time and optimize one thing at one time.

Follow these steps and
use the proper tools. You’ll have an optimized application in no time.

Contact Us