Which of these is more efficient?

The idea is this. I have an index array, and a value array. I want to get the index by searching through the index array, and then set the corresponding position in the value array to that something. There are two ways I can do this:

Code:

---

var_pos = get_index(var_names,search);
var_vals[var_pos] = new_Value;

---

or

Code:

---

var_vals[get_index(var_names,search)] = new_Value;

---

Which one's the prefered method?

As far as efficiency goes, there's probably very little difference, and I would guess you don't even need to be optimizing at this point (that should be toward the end of the development process, generally). I would say it's more of a style or even a readability issue--the second method might end up being less readable, for example, otherwise it's probably not a big deal either way.

Strictly from the "My $0.02" department, I'd lose the separate arrays, and use a std::map<indexType, valueType>. That'll give you a LOT more efficiency.

Doesn't make much of a difference. Programmers discretion as to what he/she feels is more readable. Efficiency will be determined by your search algorithm [bubble sort; divide and conquer; etc.] + structure used [ hash table; tree; array; etc.].

Whether or not to bypass the variable var_pos is trivial to a computer. Its like asking Albert Einstein whats 1+1.

Good luck!

Well, now I have to mention that Einstein sucked at math and is well known for failing it. I guess that's beyond the point with 1+1, though. :p

Second is somewhat harder to read and only saves you a single assignment operation, which should take no more than a few CPU cycles.
Unless this happens in a very tight loop in which that assignment makes up a major portion of the duration for each iteration it's not going to make any noticable difference in performance.

>var_vals[get_index(var_names,search)] = new_Value;
I like this one better, but it's a programmer preference issue. Use the one you understand.

Efficiency wise, they are identical. The compiler will do the optimization.

Ah, okay. I was really just asking because that's in a source file I'd rather NOT have split (Because it has genuinely related functions. They're just a LOT of them). It's less readable, but it's also relatively easy to unfold for debugging purposesm and I'd rather just have it condensed so that I don't have a single, 2000 line source file.

As for get_index, if I take the bounds checking out, the entire code is:

Code:

---

while(x!= search) {x++;} return x;.

---

With or without, it can get through ~70000 entries in 5 seconds. Which is roughly the same speed of just having -- erm, correction. Couting x each time makes it take five seconds. Not couting x until the operation is done takes about 1 second. It doesn't take two seconds until I increase the total number of entires to 699999. It needs to be 6999999* before major slowdown really occures. I don't know why anyone would sanely have seven million entries in a vector, though. So, er, no, it's not going to be really slow (or slow at all, really) unless the vector somehow gets really, really full of stuff.

also, I can't find a way to instantiate maps to anything. Could be a problem.

* It might take less to get slower. Prolly does. I was just using things based out of 70 entries for some reason. 1 mill is still managable.

and you could condense that to x = x + search -1; which indeed is a lot faster than the loop you use now :)