alternative to std::make_tuple
Hello,
In my function I am returning:
return std::make_tuple(rx, ry, rz);
where rx,ry,rz are floats.
Profiler shows me that exactly this consumes a lot of cpu time. I don't understand exactly why, but it is not efficient in my code.
What could be possible options, how to return 3 floats in the most simple and less time consuming way? What could be possible alternatives?
Thanks
In my function I am returning:
return std::make_tuple(rx, ry, rz);
where rx,ry,rz are floats.
Profiler shows me that exactly this consumes a lot of cpu time. I don't understand exactly why, but it is not efficient in my code.
What could be possible options, how to return 3 floats in the most simple and less time consuming way? What could be possible alternatives?
Thanks
The only more efficient way I can think of is to return the values via reference parameters.
Profilers are somewhat fuzzy about determining the exact location that's costing a lot of time. They can sometimes miss the mark by one line up or down. Are you sure it's constructing and returning the tuple that's expensive?
Profilers are somewhat fuzzy about determining the exact location that's costing a lot of time. They can sometimes miss the mark by one line up or down. Are you sure it's constructing and returning the tuple that's expensive?
You could just have a struct instance you return.
struct Point {
double x;
double y;
double z:
};
// ...
return { rx, ry, rz };
But make_tuple itself probably isn't the issue. The type of a tuple is all determined at compile time anyway.
If you're calling that part of the code a billion times, then that alone could be the issue.
struct Point {
double x;
double y;
double z:
};
// ...
return { rx, ry, rz };
But make_tuple itself probably isn't the issue. The type of a tuple is all determined at compile time anyway.
If you're calling that part of the code a billion times, then that alone could be the issue.
Last edited on
I am not sure, of course, but I heard a rumor that it can affect the thread or smth , I dont understand well ( I am also running parallel the code on the several threads). I guess my chances just try some alternatives and see.
But yes, I am calling the code many times, and possibly it will be a billion time and more.
But yes, I am calling the code many times, and possibly it will be a billion time and more.
Last edited on
Creating a tuple should not involve any synchronization or contention.
It doesn't matter how many times you run code, what matters is what percentage of the total run time is spent in the tuple.
It doesn't matter how many times you run code, what matters is what percentage of the total run time is spent in the tuple.
I am generating the chain, basically, which checks its members constantly before adding the new one, if it does not intersect with previously generated.
The runtime grows exponentially which is strange for me.
100 units - 0,3 s
500 units - 29 s
1000 units - 200 s
1500 units - 740 s
3000 units - 9450 s
For every unit the position is recalculated and compared with the new unit.
The runtime grows exponentially which is strange for me.
100 units - 0,3 s
500 units - 29 s
1000 units - 200 s
1500 units - 740 s
3000 units - 9450 s
For every unit the position is recalculated and compared with the new unit.
Last edited on
That looks like an approximately cubic growth to me, not exponential. It sounds like an algorithmic problem. You're not going to solve it with micro-optimizations.
Update:
I managed to increase speed apprx around 30% when I changed the functions to pass the references to values.
I managed to increase speed apprx around 30% when I changed the functions to pass the references to values.
Topic archived. No new replies allowed.