Select Vs Nested If statements
Blitz3D Forums/Blitz3D Programming/Select Vs Nested If statements
| ||
| Hello ;) i'm currently working with a project that has a HUGE amount of nested IF statements that is in the main loop for controls/GUI including inventory, this uses an equally large FPS, up to 130 at times. i'm currently going through and cleaning it out and was wondering the best way to do this? currently a Select statement comes to mind. |
| ||
| If your doing a lot of stuff off the same value then a select statement is the proper way to do it but performance may not be hugely different. Best way IMO is to move as much stuff to properly using types as possible :S - usually has a knock on effect of reducing the amount of hard coded if useage and moves the performance heavy stuff into the underlying C code that blitz is built on rather than being done at the blitz level. EDIT: For instance what I'm trying to get at - commonly with B3D especially for UI stuff people will do something like iterate through every instance of an object say a control doing if (control\parent = currentWindow) then blah when with a few simple tricks you can nest types into child groups and just iterate through the group thats associtated with that window - without clunky if statements or having to maintain child chains. |
| ||
| It is a matter of preference : On my machine, i have : If+Elseif+Endif ->101ms for 1000000 tests so 0.000101ms per test Select+Case+End Select -> 105ms for 1000000 tests so 0.000105ms per test The time difference is really not worth to consider. Do as you prefer. |
| ||
| this uses an equally large FPS, up to 130 at times. Remember that FPS is not linear. Losing 130 FPS out of 131 FPS is a rather different matter from losing 130 FPS out of 2600 FPS. You should expect to lose thousands of FPS as you start to add the very small things to your program and then the loss will taper off regardless of what you're actually adding, because there's less and less to lose proportionally. Miliseconds are a much better way of keeping track of what's going on because they scale in direct proportion to the work being done (they literally are the amount of time being taken to do the work). To maintain a steady framerate of 60FPS or better, your main loop needs to complete its work in under 16ms; shrink that number to make room for other things (and give the system some breathing room). I think you'll find an If or Select structure with only a few hundred elements doesn't take a measurable number of milliseconds to navigate either way (and if it does, the issue is with the functions you're calling as part of the condition checks). You can sometimes slightly improve the efficiency of GUI stuff by batching all of your GUI checks in a single place in your loop, building a record of "all the things that happened", and then query this custom list of events yourself by simply testing the variables in it rather than spreading GUI poll commands out throughout your logic. Also the GUI itself may have a measurable effect on your program (e.g. it's very nice to look at but a program using the BCF GUI just plain isn't going to run at above 30FPS or so because the GUI itself is slow). |
| ||
| yasha your information is always clear and very educational :) i suppose its not as bad as i initially thought but it still needs cleaning out, the inventory system alone uses about 4-5 MilliSeconds. Rroff could you give an example of using types for GUI? i'm having trouble picturing how it would be done though yasha's mention of GUI does sound similar to what you were talking about. thanks everyone. |
| ||
| First thing to ask is why you need to use 130 if statements? ' If it is since item 1 might have X or item 2 might have X or item 3 might have X then what you need to do is keep track of the existence of X. When a player picks item 1 or 2 or 3 mark down that X is now in the player's inventory, then you just need to make a single check using 1 if statment. This is similar to what Rroff is saying. Another way to say it is to do the checking as little as possible and keep track of as much as possible since this keeps down the amount of checking that needs done at any one point. |
| ||
| i wasnt that specific about the amount of statements, there is a hell of a lot more than that and i'm not the one who made it. :P thanks, that helps me a bit. |
| ||
| Hand me down disasters, gotta love those! For a quick and dirty short term fix, see if you can ADD if statements (stay with me). The idea would be to try and half the number of if statements actually executed. This works best if you need to check if a value is 1 or 2 or 3 or (up to 130). So checking for 1 to 140 If X < 71 then else end if Then within that if check for <36, then <18, etc... It is ugly but I have actually needed to do things like that to horrible code - giving me time to fix it up correctly later. |
   |