Concerns about the effectiveness of code Topic is solved

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
Louigi Verona
Earned some good credits
Earned some good credits
Posts: 127
Joined: Tue Mar 24, 2009 10:21 am
Contact:

Concerns about the effectiveness of code

Post by Louigi Verona » Thu Jul 23, 2009 2:48 pm

Each time I am adding an if clause, I am thinking - this will make my app slower since it needs to process another clause. At the same time it is usually the right course of action, since the app requires that logic.

So I was thinking whether my concerns are valid at all. For instance, if I am running a timer and the OnTimer event has a clause which seems to be required there but which is true only rarely, it means that each time the OnTimer event happens, processor has to evaluate this clause and this eats up resources and time, even if small. Is it true that this eating up is significant or can the computer actually process thousands of clauses without any significant delays?

Another usual situation is the processing of the keyboard events. If the app realizes the recursive scheme, then the KeyDown function has all the keyboard events in it and that means a very big set of clauses - if, else if, else if. And if the required key code is at the end of the clause line, it seems that it will be processed much later.

yuri
Earned some good credits
Earned some good credits
Posts: 104
Joined: Thu Apr 09, 2009 4:58 pm
Location: Russia

Re: Concerns about the effectiveness of code

Post by yuri » Thu Jul 23, 2009 3:21 pm

Typically it is not an issue at all. For computation-intensitive code however it is possible to use switch statement that is faster for many branches, or profile-based optimisation. But if you need this you would know this :)

Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria » Thu Jul 23, 2009 5:25 pm

What makes an app slower is rarely if checks, much more loops. So don't worry ( unless your if is called in a long loop, or calls a long loop ;) )

As a general rule, don't care much about performance until you try it and see it's too slow. Then you can think about making it faster
"Keyboard not detected. Press F1 to continue"
-- Windows

Romas
I live to help wx-kind
I live to help wx-kind
Posts: 176
Joined: Mon Jun 16, 2008 11:07 am
Location: Kaunas

Post by Romas » Thu Jul 23, 2009 7:08 pm

Your thinking is not very constructive, rather destructive. Everytime you have this kind of idea, you slow your developement process, not the program itself :) So, in first case - drop those thoughts out of your head and write [any] code. After that, when your deadline is not too close, you can polish most concerned places. This is my honest advise.

On the other hand, if statements will not make your code slower, the logics will. Think in this way, maybe you can split you super duper mutant thousand if function in two functions, add additional switch sentence etc... :) Use KISS principle :)

I will agree with Auria, loops kills the speed, especially double, tripple, quadruple etc.. loops are the killer (and memory allocation operations).

Enough phylosophy, let's code :twisted:

Louigi Verona
Earned some good credits
Earned some good credits
Posts: 127
Joined: Tue Mar 24, 2009 10:21 am
Contact:

Post by Louigi Verona » Fri Jul 24, 2009 4:34 am

Well, in the application I am writing now I do not have ANY loops at all, tbh. Not that I remember at least. So thanks guys, it is good to know. I will consider using switch for processing keyboard events.

upCASE
Site Admin
Site Admin
Posts: 3176
Joined: Mon Aug 30, 2004 6:55 am
Location: Germany, Cologne

Post by upCASE » Fri Jul 24, 2009 6:24 am

Hi!
Another thing to consider is that modern compilers do a pretty good job optimizing code most of the times, especially optimizing loops.

In most cases compilation time will be higher when having the compiler run with an option like O3, but the resulting code should be "faster". For loops, techniques like unrolling will be performed. For "if" statements, branch optimizations will be applied. So it's not that what you wrote in your code will be the actual program path. The path will be optimized using the correct options, thus reducing execution time.

Bear in mind, however, that optimization sometimes may not be desired. I had a problem once that I could track down to optimizations of the compiler. I suppose it was a rare case and I still don't fully understand it (recursion where due to the optimization a variable wasn't assigned the correct value).

Yet another thing is that you talk about user input. For keyboard events, I wouldn't really consider them to be time critical. As long as there is no input, no action will be taken. And most of the times you wouldn't notice any difference in speed if the choice of action was using "if else if" branches. It's more important IMHO that your app doesn't block once an action is taking place.
OS: OpenSuSE, Ubuntu, Win XP Pro
wx: svn
Compiler: gcc 4.5.1, VC 2008, eVC 4

"If it was hard to write it should be hard to read..." - the unknown coder
"Try not! Do. Or do not. There is no try." - Yoda

Jorg
Moderator
Moderator
Posts: 3971
Joined: Fri Aug 27, 2004 9:38 pm
Location: Delft, Netherlands
Contact:

Post by Jorg » Fri Jul 24, 2009 6:31 am

My teacher always said;

1. Make it simple
2. Make it work
3. Make it optimized

First make your app as simple as possible. Every diversion of the main train of thoughts only distracts you from that goal. Write thoughts down and continue. Then make it work. Meaning make it bug free and well tested. Then when you guarded your app / algoritm with test cases, and only THEN you should think about optimization. This has the advantage that when you break some boundary condition, your tests will tell you and the optimization won't break anything.

After this cycle go to the next cycle. Which can be expanding the current feature, refactoring it, or adding new features

With regards,
- Jorgen
Forensic Software Engineer
Netherlands Forensic Insitute
http://english.forensischinstituut.nl/
-------------------------------------
Jorg's WasteBucket
http://www.xs4all.nl/~jorgb/wb

Louigi Verona
Earned some good credits
Earned some good credits
Posts: 127
Joined: Tue Mar 24, 2009 10:21 am
Contact:

Post by Louigi Verona » Fri Jul 24, 2009 7:29 am

Thanks for the advice guys. Very interesting reading.

yuri
Earned some good credits
Earned some good credits
Posts: 104
Joined: Thu Apr 09, 2009 4:58 pm
Location: Russia

Post by yuri » Sat Jul 25, 2009 5:57 pm

Jorg wrote:My teacher always said;

1. Make it simple
2. Make it work
3. Make it optimized
Very good advise indeed. However before step 1 one should still estimate constraints on the program, including algorithm complexity and timings.

Failing that, one would easily come with simple and elegant solution that works fine on test cases but fails miserably on real life workload. And refactoring complex project late may be very expensive.

That said, most GUI-related programs idles most of the time anyway, so few extra if's and loops won't hurt anyone :)

webmasterpdx
Knows some wx things
Knows some wx things
Posts: 27
Joined: Thu Jun 25, 2009 2:43 am
Location: Portland, Oregon
Contact:

Post by webmasterpdx » Sun Jul 26, 2009 12:28 am

I'm mostly an embedded developer and that is where you run into the kinds of problems you are talking about, but that is one a 4MHz PIC processor or something running a GUI on an LCD.

On a modern PC running a multi Gigahertz clock and super fast front side bus (memory), you have nothing to worry about unless you are doing something involving millions of events per second. If you are doing that, you are probably doing something wrong, or you need to use a real time OS if you are controlling critical hardware (QNX runs on a PC and is hard real time and has a nice GUI environment). Looks and feels like Linux too.

However, you shouldn't have a problem with anything involving soft real time on a PC for most applications today.
There are also tricks that you just learn through experience to allow other processes to execute. e.g. If you are waiting for some event....rather than loop and wait, either put a sleep call inside the loop (which gives other processes time to execute), or make a call to a pending wait function that will hand off executiong to another thread until the event you are waiting for happens.

There are also good tips pointed out above about keeping things simple....the saying is actually KISS "Keep It Simple Stupid". That alone will solve all kinds of headaches.
Also it helps to try and modularize to try and partition your design into independent subsections that interact together through a well defined interface. Then, each partitions should be much simpler than the whole...

Good luck
-D

Post Reply