On 4/22/22 16:51, Francisco Casas wrote:
Hello,
April 22, 2022 3:45 PM, "Zebediah Figura" zfigura@codeweavers.com wrote:
On 4/22/22 09:11, Francisco Casas wrote:
Hello, April 22, 2022 6:51 AM, "Giovanni Mascellani" gmascellani@codeweavers.com wrote: Hi,
I am not completely in love with the additional runtime complexity of this solution, but it's true that it's quite clean.
I have a couple of ideas for lowering the complexity: a) Add a "component_count" field to hlsl_type in order to store/cache the result of hlsl_type_component_count(). Which would also speed up other parts of the compiler. b) Add a "comp_offsets" array to "hlsl_type.e" so that the right field that has a given component can be selected in hlsl_compute_component_reg_offset() using a binary search. I can make new patches for these.
I guess you mean time complexity? I don't think there's any reason to worry about that, especially not with initializers.
Yes, I meant time complexity, sorry.
I only see an O(n^2) worst-case scenario, for the initialization of a struct n components. So yes, it is probably not worth worrying about it.
Well, that, but more importantly, n is always going to be small.