What's less resource Intensive? in Developer Help

ID:158090
 
Nov 4 2009, 6:20 am
Not sure if I should put this in design philosphy, but alas,

What is more resource intensive, calling a proc everytime X calls Bump(), or putting it right into Bump()?

Before you mock me, I have my reasons...

If I put it right into Bump(), then I will be left with a VERY long Bump() function, i.e
thingy/Bump(atom/A)
 if(A.istype(/obj/stuff/blag))
  var/obj/stuff/blag/B = A
  B.health-=number
  //do blag specific stuff
 else if(A.istype(/obj/stuff/blog))
  var/obj/stuff/blog/B = A
  B.health-=number
  //do blog specific stuff
//I think you get where this is going, and there are around 10 or so of these that must be done


Whereas I can make a proc, e.g Bumped(), specifically change it for each of the atoms that when bumped do stuff,
and thus make my code alot cleaner, e.g
thingy/Bump(/obj/stuff/A)
 A.Bumped(number)

obj/stuff/blag
 proc/Bumped(number)
  src.health-=number
  //do blag specific stuff



What I'm wondering, is which is more resource intensive, efficient or for lack of a better phrase, less lag inductive.

kthx
R_shn_t
#1 Nov 4 2009, 7:19 am
I don't think your going to see a big difference either way, but having a separate bumped proc for each atom being bumped is going to be a little less processor intensive... slightly. The only thing your really saving on CPU with per bump are a few checks to see what kind of atom your dealing with to act accordingly, but then again saving a little bit in a lot of places can make a big difference.
#2 Nov 4 2009, 7:27 am
In response to Jotdaniel (#1)
Indeed it can in an 8mb.rsc game ;)
#3 Nov 4 2009, 9:50 am
In response to Jotdaniel (#1)
Jotdaniel wrote:
but having a separate bumped proc for each atom being bumped is going to be a little less processor intensive... slightly.

That should probably be "might be" instead of "is going to be." Are you sure that Byond checking to see what type of object something is and calling another function is going to be faster than you checking to see if something is a certain type of object and maybe (maybe not) jumping to a different instruction instead of continuing with the next one?
#4 Nov 4 2009, 12:25 pm
The object-oriented approach is essentially better in every way.
#5 Nov 4 2009, 12:27 pm
In response to Kaioken (#4)
Care to explain?
#6 Nov 4 2009, 3:03 pm
The difference is absolutely trivial. Use the method which is easier to build, maintain, and modify.
#7 Nov 4 2009, 11:30 pm
In response to Rushnut (#2)
Rushnut wrote:
Indeed it can in an 8mb.rsc game ;)

Just because you happen to have a 8 MB resource file does not necessarily mean that your game classifies as "big". It could just mean that you suck horribly at optimizing your resources, by sticking BMP and WAV files in the resource file. Nevertheless even if you do use your PNGs and OGGs wisely, it's still not a reliable indicator that your game is big, it only indicates you put a lot of effort in the graphics and sounds.

Personally I would use Bumped() vs. Bump() and use a combination of the two when needed.

You should use Bump() if you wish to perform a default action that isn't necessarily object-specific (i.e. "pushing" an object forward if it isn't stuck to the floor), and use Bumped() if you wish to perform object-specific tasks (i.e. teleporting a player if they enter a portal).

The difference between the two is negligible, even on older machines. What you should focus on is not small things like this, but procs that perform a lot of calculations. Simply redirecting to another proc doesn't eat up a lot of CPU.

A tip: If you compile your game in DEBUG mode, you can use the "Profile World" option while you're hosting it to determine which procs are the source of excessive CPU usage. I recommend you use that and focus on the procs that use the most rather than petty things like Bump() vs. Bumped().

Word of caution: Initially you don't want to worry about the "real time" field in Profile World but more on the self/total CPU time. The real time field is incremented even if you sleep in a proc and does not always reflect that a proc is using a lot of CPU. Total CPU is what you'll want to look at.
#8 Nov 5 2009, 1:12 am
In response to Rushnut (#5)
The series of if-statements will be converted into something like this:

check condition 1
conditional branch
(some code)
check condition 2
conditional branch
(some code)
check condition 3
conditional branch
(some code)

In order to do a function call on an object, the machine has to do this:
lookup function pointer in object vtable
call function (with stack push)
(some code)

It's difficult to tell which is faster for any specific case, but the function call case is a constant cost, whereas the series-of-conditions case is going to get more expensive as you add more conditions.

On the other hand, if you know one condition will happen much more often than any others, you can optimise the series-of-conditions case by whacking the popular one up the top.

This is all irrelevant, anyway, because the first thing I should have said is "Premature optimisation is the root of all evil". It ain't gonna matter.
#9 Nov 5 2009, 1:15 am
In response to Android Data (#7)
(I have not yet read the rest of your post, and will continue to do so, I just wish to point out that I have all .ogg sound files and not many at that. It truly is all coding.)
#10 Nov 5 2009, 1:18 am
In response to Android Data (#7)
The problem is, with my game, unlike other games where you might get a dollar per kill, or a point per rescue, my game you get a point per kill, and a point per rescue, then it is calculated how much money, or the suchlike, at the end of the round. Alot of my functions follow this method.
#11 Nov 5 2009, 1:57 am
In response to Rushnut (#9)
Rushnut wrote:
(I have not yet read the rest of your post, and will continue to do so, I just wish to point out that I have all .ogg sound files and not many at that. It truly is all coding.)

Precisely zero percent of your .rsc file is "coding". Code is compiled into the .dmb, not the .rsc. The .rsc contains - surprisingly enough - resource files.
#12 Nov 5 2009, 1:58 am
In response to Garthor (#11)
Then please stand back whilst I hit my head against this conveniently placed lamp-post.
#13 Nov 5 2009, 2:06 am
In response to Rushnut (#10)
Rushnut wrote:
The problem is, with my game, unlike other games where you might get a dollar per kill, or a point per rescue, my game you get a point per kill, and a point per rescue, then it is calculated how much money, or the suchlike, at the end of the round. Alot of my functions follow this method.

Irrelevant. First of all, I have no damn clue what you're talking about, and how it's relevant to anything. Going past that, however, you need to realize that events such as this are occurring very rarely, relative to CPU cycles. Each player is limited to one action per tenth of a second. In that length of time, my computer is able to perform 310,000,000 operations. Granted, they are very small operations, but there ARE 310 million of them.
#14 Nov 5 2009, 2:07 am
In response to Garthor (#13)
Then why is lag an issue for me then? Granted I might not have the greatest computer, but that doesn't mean that I should be lagging when I'm hosting.
#15 Nov 5 2009, 2:09 am
In response to Rushnut (#14)
There are a large number of possible reasons. The function stack is not one of them.
#16 Nov 5 2009, 5:13 am
In response to Loduwijk (#3)
Given what he was stating, that he is going to have different procedures for each type of atom he wants bumped, he would have to check what type of atom he is bumping and then write the appropriate block of code in the bump proc, I don't see how that could possibly be better then just switching to a different proc and executing that atoms block of bumped code. I don't see how that could possibly be more efficient than doing a type check.