1

in the process of refactoring some code, want to change a function like this

bool A::function() {


return this->a == this->b || this->c == this->d || this->e == this->f || this->g == this->h ;

}

to something like this

bool A::function(int a, int b, int c, int d, int e, int g) {


return a == b || c == d || e == this->f || g ==  this->h ;

}

this function is supposed to be called each time inside a main loop which would have at most 10M elements

The people I'm working with are reluctant to use the second version because of the performance cost of passing 6 ints. I'm pretty sure that this is negligeable, considering that each iteration of the loop goes through a LOT of code, and it roughly takes ~1 minute to proces the 10M elements.

Is the cost of passing 6 int by value all the time so hight? if not, how can I make them change their mind?

edit : about inlining, I told them that the penality would be 0 if the function was inlined but their answer was basically "we can't know for sure if it will be inlined", which I seem to recall is true (up to the compiler)

lezebulon
  • 7,607
  • 11
  • 42
  • 73
  • 2
    Are `a`,`b`,... logically part of the class or not? – Luchian Grigore Jul 17 '13 at 11:23
  • 2
    If the function inlines, six ints won't be passed. If it doesn't, then it's probably big enough that the cost of passing six ints is lost in the noise. – David Schwartz Jul 17 '13 at 11:25
  • 1
    @Luchian Grigore : well in the old version they are, in the new version they still are. But in the new version we want to add the ability to call "function" with data that isn't in the class, because it can be reused elsewhere – lezebulon Jul 17 '13 at 11:25
  • and `A::f()` is not being inlined? – TemplateRex Jul 17 '13 at 11:26
  • @David Schwartz : "function" is littreally just a bunch of OR tests like in my example, maybe just 2 or 3 times more – lezebulon Jul 17 '13 at 11:26
  • In my view, is better the first function, if you delare it as inline, because the compiler will transform this function in the tests, the second choice has a lot of innecesary variable copies. – superarce Jul 17 '13 at 11:30

3 Answers3

2

I suspect that you won't see any big difference between these two variants in reasonably optimised code. However, the proof of that would be to actually change the code and compare the different times. (And more so if 10M entries are being processed in a minute, that's 6 microseconds per item, so around 30000-200000 instructions on a modern processor - adding 6 argument passes won't budge it one or the other way, I'd say - unless this function is called many times in the loop, of course).

And yes, if the function is inlined, the result would be identical code for the two alternatives - but are your colleagues say, you can't know for sure that it is inlined or not - the only way to really determine that is to have a look at the generated machine-code (-S or use objdump or similar).

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
2

In terms of performance, I would suggest you profile your code, and see if there is a difference that matters. Passing ints around is usually very cheap and open to automatic optimization, so I doubt you would see a measurable performance hit.

Also worth pointing out that the two functions are different. The second doesn't necessarily use the member variables and the first does. If you're always comparing member variables, why pass them as parameters? Extra unnecessary parameters means more source code and a greater scope for bugs.

SmacL
  • 22,555
  • 12
  • 95
  • 149
2

Write the code and as Shane says, profile it, or I prefer to grab a few stack samples because you can see exactly what's going on.

If you find the program counter in the instructions that pass those int arguments, on more than one sample, then they are costing a significant fraction of time, and you should do something about it.

On the other hand, the samples might tell you something else is the main time-taker, and maybe you should fix that first. Then the program will be faster, and if you do the whole process again, it might come back to your original question.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135