Conversation
There was a problem hiding this comment.
Makes sense to me to simplify these functions; they're definitely more complex than they need to be.
However, initializer_list has a hidden cost for non-trivial types. You can read about this problem here: godotengine/godot-proposals#12247
We've chosen to ignore this problem in most cases, since it's unlikely to lead to problems for most allocations.
However, as commonly called functions, varray and vformat deserve some extra care.
In practice, instead of using initializer_list, I'd probably create the vector, reserve on it (#105928 is scheduled to be merged early in 4.6), and then push_back items from p_args sequentially. This should both simplify and optimize the code. (or, alternatively, resize and loop through the args, assigning to ptrw(). This should be even faster but might be more annoying to implement).
fd38b09 to
aece13e
Compare
|
I changed |
|
I forget there is already #103917 😅. That should supersede |
aece13e to
6dd71ce
Compare
Ivorforce
left a comment
There was a problem hiding this comment.
I just realized args necessitates a copy anyway, in the same vein that initializer_list does. Therefore, this shouldn't be a performance regression.
The whole initializer_list thing is still relevant, but since it has no satisfying solution yet, I'm OK just simplifying the code for now.
6dd71ce to
8f36c97
Compare
|
Thanks! |
Reduce complexity of these two functions with initializer list constructor.
varrayshould be ok because it is used together withsarray, so not performace critical.For
vformatI run both microbenchmark and a test project:code
result
master:
vformatThis PR:
vformatcode
result
master:
175.029 ms
172.557 ms
170.201 ms
172.307 ms
172.757 ms
172.753 ms
172.192 ms
171.617 ms
171.543 ms
173.941 ms
average: 172.4897 ms
This PR:
171.95 ms
170.445 ms
170.952 ms
168.081 ms
169.044 ms
170.402 ms
170.3 ms
171.469 ms
171.817 ms
169.767 ms
average: 170.4227 ms
both tests show no regressions.