You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you like to be cleaned: FlavorResourceQuantities, a map[string]map[string]int64, is ubiquitous in the codebase. We have a lot of code that processes it in a nested loop, often allocating the inner map in the middle. It started getting in my way during the implementation of #79, and I started using a flat version of this map, resulting in significantly simpler code.
Unfortunately, this type is everywhere and the refactor is quite involved. I propose the following steps:
Move FlavorResourceQuantities to its own package
Define new types, a FlavorResource tuple, and FlavorResourceQuantitiesFlat
Update tests without changing functionality - we will define test data using the new type, but convert it back to the old type with a helper function
Update non-test source to use this new type
Cleanup; rename FlavorResourceQuantitiesFlat to FlavorResourceQuantities
The first three parts are safe. The 4th part has more risk, and can be done alongside the implementation of #79.
Why is this needed:
This old type is a mismatch for the problem, and is resulting in unnecessarily nested/complex code.
To help motivate this change, and see why I think the type is a better fit for the problem, consider the following refactors which were possible:
this was reduced to a single for-loop without branching
What would you like to be cleaned:
FlavorResourceQuantities
, amap[string]map[string]int64
, is ubiquitous in the codebase. We have a lot of code that processes it in a nested loop, often allocating the inner map in the middle. It started getting in my way during the implementation of #79, and I started using a flat version of this map, resulting in significantly simpler code.Unfortunately, this type is everywhere and the refactor is quite involved. I propose the following steps:
FlavorResourceQuantities
to its own packageFlavorResource
tuple, andFlavorResourceQuantitiesFlat
FlavorResourceQuantitiesFlat
toFlavorResourceQuantities
The first three parts are safe. The 4th part has more risk, and can be done alongside the implementation of #79.
Why is this needed:
This old type is a mismatch for the problem, and is resulting in unnecessarily nested/complex code.
To help motivate this change, and see why I think the type is a better fit for the problem, consider the following refactors which were possible:
this was reduced to a single for-loop without branching
kueue/pkg/cache/clusterqueue.go
Lines 520 to 532 in 53a0341
this was reduced to a single for-loop, with only 1 more level of branching (the if statements)
kueue/pkg/cache/clusterqueue.go
Lines 534 to 555 in 53a0341
/assign
The text was updated successfully, but these errors were encountered: