September 20, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Simple Rules that Boost Your Mobile Application's Performance

  • November 10, 2006
  • By Alex Gusev
  • Send Email »
  • More Articles »

Loops and Repeated Code

Look at the following code snippet:

void CSomeClass::SimpleOp(TSimple& aSimple1, TSimple& aSimple2)
{
...
   CComplex complex = CreateComplex(aSimple1);
   // use complex somehow but don't modify it
...
}

void CSomeClass::ComplexOp()
{
   TSimple s1, s2;
   while (expr)
   {
      SimpleOp(s1,s2);
      // do something but don't modify s1
      ...
   }
}

As you can see, a variable of CComplex type is created in the SimpleOp function, but never modified later on. Hence, a call to SimpleOp at every loop iteration is absolutely redundant and can be removed:

void CSomeClass::SimpleOp(CComplex& aComplex, TSimple& aSimple)
{
...
   // use aComplex somehow but don't modify it
...
}

void CSomeClass::ComplexOp()
{
   TSimple s;
   CComplex c = ...;    // create an object of CComplex type somehow
   while (expr)
   {
      SimpleOp(c,s);
      // do something but don't modify s1
      ...
   }
}

In fact, such complex type creation may be quite an expensive operation, so dragging it out of the loop may add its bit of fuel to the overall application performance fire.

Type Conversions

It may seem funny, but how many times you have been faced with the situation when you have had to make many subsequent conversions just to transform data from one representation to another, as in the following snippet:

TIntType nInt;
TCharType cChar = GetCharFromSomeData();
ConvertCharToInt(cChar,nInt);
TMoreComplexType aObj = SomeFunc(nInt);

It might be a legacy system that determines the stored data format, but in many cases it is just a bad design resulting in an unnecessary waste of processor time. You obviously should avoid it where possible.

Another aspect of the 'type' problem is when you need some temporary object to interface to some data; for example:

aObject.Func().DoSomething();
aObject.Func().DoSomethingElse();
aObject.Func().DoSomethingAgain();
...

Putting aside unnecessary function calls, a new temporary object is created on the stack after each call to aObject.Func(), which is not so good by itself. A situation may become even worse when you intended to have Func() as inline, but the compiler was commanded to produce the smallest code size. Thus, for frequently used functions, it may decide to skip this inline qualifier without letting you know about it! Having said this, it's much better to re-factor the above code as follows:

CSomeType aObj = aObject.Func();
aObj.DoSomething();
aObj.DoSomethingElse();
aObj.DoSomethingAgain();
...

You can justly say that this all is obvious, but...simply recall how many times you have seen it yourself.

Work with Your Compiler, not Against It

In all modern IDEs, compilers do a lot of optimizations to produce either smaller code or a faster execution path. Therefore, it is always a good practice to learn the basics of the compiler you are going to use in your development. Such knowledge will allow you to predict more accurately the final outcome and relate it to the code you write, thus avoiding a generation of inefficient binary for some particular cases. Besides, learning a little bit about an assembler also can help you understand what's going on.

Conclusion

This article discussed several simple yet destructive 'performance killers' tbat may cause an unacceptable decrease in performance. In many cases, you can avoid such 'bad practices' and then focus on some other components that affect the overall effectiveness of your particular application; for example, external legacy systems, databases, networking, or whatever else. Hopefully, this article will help you on this rocky way.

About the Author

Alex Gusev started to play with mainframes at the end of the 1980s, using Pascal and REXX, but soon switched to C/C++ and Java on different platforms. When mobile PDAs seriously rose their heads in the IT market, Alex did it too. After working almost a decade for an international retail software company as a team leader of the Windows Mobile R department, he has decided to dive into Symbian OS ™ Core development.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel