NewLC - Performance Tuning of Code - Comments

Re: Performance Tuning of Code

crammond — Sat, 14 Nov 2009 13:51:24 +0100

Thanks for sharing. This is very helpful. Hope you can share more

eve isk

Re: Performance Tuning of Code

Willi — Tue, 29 Jul 2008 10:33:53 +0200

Very useful article. But still there is a scope to add a spice.
"Code snippets" can be added to elaborate the issues like in Array and TRAPS usage.
Thanks

Re: Performance Tuning of Code

Isha — Mon, 23 Jun 2008 15:39:35 +0200

Hi,

It's really a very nice article and very helping also.

thanks&Regards
Isha

Re: Performance Tuning of Code

cheers — Mon, 16 Jun 2008 15:09:24 +0200

Hi GB San,

Nice to see your feedback. Profiler is something which we use to get the running behavior of our code/application in terms of memory/power/CPU time utilization. Another beautiful tool is Bappea it is another powerful analysis tool and its GUI is also user friendly but I am not sure that it is available outside.

Cheers,
Reeju

Re: Performance Tuning of Code

cheers — Mon, 16 Jun 2008 09:52:43 +0200

Hi Olof,

Thanks for the feedback. I have updated #12 and #11.

Cheers,
Reeju

Re: Performance Tuning of Code

banerjee_008 — Mon, 16 Jun 2008 04:08:25 +0200

Nice article !!!

you have definitely pointed out good programing methods for better performance while developing code. any thoughts on identifing such flaws for an already developed code as you mentioned performance tools like profiler in the opening para?

Re: Performance Tuning of Code

alh — Fri, 13 Jun 2008 12:06:58 +0200

Nice article!

#11 do need some more clarification though, as previously mentioned.

Also, in #12, I think you talk a bit too much about the CBase-arrays, and a bit too little about the R-arrays.
You do say that R-arrays are preferred, but you mostly talk about the CBase-arrays.
A bit more about the R-arrays, maybe a bit more about the difference between an RPointerArray and RArray, and when you should choose which of those.
And also clarify its very seldom you need any other type of array then the R-ones, and you should never need to use the flat CBase-array....

Re: Performance Tuning of Code

Andreas — Thu, 12 Jun 2008 14:14:11 +0200

True. Maybe the article could just clarify the role of pointer descriptors. Many times newbies try to use pointer descriptors as if they would hold data (or even TDesC!) and not understanding that they actually themselves do not contain any data but point to a data in some other descriptor. So clarifying this and leading the readers to use pointer descriptors as you described would be better. And this is directly related to performance too.

Re: Performance Tuning of Code

eric — Thu, 12 Jun 2008 13:38:22 +0200

I don't totally agree on your #11 Andreas. It is sometimes good to push people to use TPtr/TPtrC when they can. I have seen so many poor usage of TBuf just to extract substrings than a small reminder about these is always welcomed.

Re: Performance Tuning of Code

cheers — Thu, 12 Jun 2008 12:40:54 +0200

Hi heikkipora,

I gone through your article its worth of reading. Thanks for the link.

Cheers,
Reeju

Re: Performance Tuning of Code

heikkipora — Thu, 12 Jun 2008 07:52:05 +0200

A related article probably worth reading is http://www.newlc.com/Application-Size-Optimisation-in.html

Re: Performance Tuning of Code

cheers — Wed, 11 Jun 2008 11:04:56 +0200

Hi Andreas,

Thanks for your feedback sure i will do required changes in my article.

Cheers,
Reeju

Re: Performance Tuning of Code

Andreas — Wed, 11 Jun 2008 10:07:37 +0200

Comments:

#10: In a general article like this, try to avoid using S60 or UIQ specific APIs to make your article really general. SysUtils is S60, AFAIK. RFs::Volume provides the same information.

#11: TPtr and TPtrC are pointer descriptors, pointing to some descriptor data somewhere else. They themselves do not solve any problem. You should only talk about stack (TBuf/C) versus heap descriptors (HBufC/RBuf). Selecting between RBuf and HBufC, in relation to performance -- RBuf has a simpler API and is easier to use, but you do not explain what is the actual performance issue here? HBufC is also dynamic. Regarding the 16 char max size for stack descriptors -- IMO you are a bit too much optimizing here. Usually in Symbian docs they mention that TFileName is about the max you are recommended to use, and TFileName is 256 chars (512 bytes in unicode). This also depends on the application. If you already consume the stack a lot, then try to avoid automatic stack descriptors. Which reminds me that you can safely put TBuf/C:s as member variables of C -classes, since they are on the heap anyways (which should also be mentioned).

Articles like this are needed, thanks for summarizing things. Hopefully you will continue to edit this!

Performance Tuning of Code

cheers — Wed, 11 Jun 2008 09:18:28 +0200

If an application runs and performs all required task for the user or client, doesn’t means that it is complete in all the sense. Using performance analysis tools like profiler we can find out how our application is performing internally means in terms of speed, memory usage and power utilization. There are lots of issues which can reduce performance of your application; and here is a list of some of them