| closedmost time faster if's |
| Started by ghzero on 04-05-2009, 09:55 AM |
ghzero
Threads: 42
Joined: Sep 2007
hello,rnI noticed that some plugin having many OR's (||) in their if routine,rnI think that this will stress the cpu more as an new IF in most situations.rnrnis that right or false what I think?rnrnfor example..rnrnoriginal IF in fakemeta's touch(id,ent)-forward:rnif(!pcvar_tackle || !pev_valid(id) || !pev_valid(ent) || id>32 || ent>32|| id<1 || ent<1 || g_round_restart)rn return FMRES_IGNOREDrnrnthe solution if my thinking is right will be:rnif(!pcvar_tackle || g_round_restart)rn return FMRES_IGNOREDrnif(ent<1 || ent>32)rn return FMRES_IGNOREDrnif(id<1 || id>32)rn return FMRES_IGNOREDrnif(!pev_valid(ent))rn return FMRES_IGNOREDrnif(!pev_valid(id))rn return FMRES_IGNOREDrnrn..what do you think ? (or know)
Dr.G
Threads: 75
Joined: Nov 2007
every time you do an if you will compare something... so you are asking. Will:rnrn
COMPARErnrnstrees the cpu more then:rnrn
COMPARErnCOMPARErnCOMPARErnCOMPARErnCOMPARErnCOMPARErnCOMPARErnrni know that you would think now: "You cant say it like that, because the first COMPARE is way bigger then the next once!" Then think of it like this:rnrn
GET_VALUErnGET_VALUErnGET_VALUErnGET_VALUErnGET_VALUErnGET_VALUErnGET_VALUErnCOMPARErnrnVS:rnrn
GET_VALUErnCOMPARErnGET_VALUErnCOMPARErnGET_VALUErnCOMPARErnGET_VALUErnCOMPARErnGET_VALUErnCOMPARErnGET_VALUErnCOMPARErnGET_VALUErnCOMPARErnrnSo what do you think now? This is however how i understood it should work, i might be wrong tho....
ghzero
Threads: 42
Joined: Sep 2007
yes, 6x IF in row will by more stress as ONE IF-line..if required.rnrnbut, the touch forward will forward all touches, so a huge times it will run this forward without the requirement of the usage of that routine.rnrntheory:rn60 percent calls of that forward that are not required...forward will end after (maybe) the 3rd IF.rn40 percent calls of that forward are used by plugin in real.rnrnso in 60 percent of the calls we have lower stress for the cpu by the limited amount of compares!
Dr.G
Threads: 75
Joined: Nov 2007
i wouldnt split the if checks up, the main reason why is cuz iam pretty sure it works like i posted above, and i have never seen any of the hardcore scripters do it. Now something that will stress you server is prethink, and that can really fuck up things if you make any errors.
ghzero
Threads: 42
Joined: Sep 2007
yes, I know the problems that can happen in high frequency forward/routines like prethink() or damage().
diamond-optic
Threads: 103
Joined: May 2005
well i asked and used this as an example:nn
nif(!this || !that || !something || !etc || whatever || evenmore || !yadayada)n return FMRES_IGNOREDnnif(!this || !that)n return FMRES_IGNOREDnif(!something || !etc)n return FMRES_IGNOREDnif(whatever || evenmore)n return FMRES_IGNOREDnif(!yadayada)n return FMRES_IGNOREDnFirst one is just fine, if this == 0, other statements won't be checked.nn
If you're hoping to avoid checking the values, make sure you put them in the following order:nnif( !most_likely_to_be_zero || ... || ... || ... || !least_likely_to_be_zero )nnor, more clearly:nnif( most_likely_to_be_true || ... || ... || ... || least_likely_to_be_true )nnnn
I usually put statements that doesn't require a native call before the other one.nIn the last example you gave, i would for example put "ent > SETTING_MAXPLAYERS || g_round_restart" at first.nnnso from what i gather.. having one if statement is fine, if not better.. but ordering the checks could have some improvement
=|[76AD]|= TatsuSaisei
Threads: 54
Joined: May 2005
diamond and vet have the correct answersn nThe way any program is executed during an OR is that it ceases all other checks upon finding the first TRUE value and renders the OR output to be TRUE, the AND shares a similar situation in the all other checks are ceased the moment a FALSE is found and renders the output of the AND to be FALSEn nKnowing this then n
IF (this || that || other) nIF (this)nIF (that)nIF (other)nThreads: 103
Joined: May 2005
look whos back from the dead!
ghzero
Threads: 42
Joined: Sep 2007
|= TatsuSaisei;12753']diamond and vet have the correct answersrn rnThe way any program is executed during an OR is that it ceases all other checks upon finding the first TRUE value and renders the OR output to be TRUE, the AND shares a similar situation in the all other checks are ceased the moment a FALSE is found and renders the output of the AND to be FALSErn rnKnowing this then rnrnrn..but if the MOST times the first IF will result an false it can spare cpu-time if we split the IF's to single... do you think so too?rn rnwould be "better" as opposed to splitting it into "many" seperate IF checksrn rnIF (this || that || other)rnIF (this)rnIF (that)rnIF (other)rn
Vet
Threads: 24
Joined: Oct 2006
I'll agree with that. I'll insert a dedicated 'if' when I know the result 90+% of the time. Especially with strings involved or if its a routine that gets called often, like a 'think' routine.