Clean up code handling both std::vector and SmallVector

[zcbenz]

Using SmallVector does not always have performance gain over std::vector in all cases so we are having code handling both std::vector and SmallVector, this PR adds a is_vector type trait to make the code easier to maintain.

[awni]

Using SmallVector does not always have performance gain over std::vector in all cases so we are having code handling

Can you elaborate on that? Where do we not get perf gain / where are we using std::vector still for shapes and dtypes?

[awni]

Looks good. I'm slightly confused as to the purpose .. but feel free to merge the cleanup as it seems useful regardless.

[zcbenz]

Can you elaborate on that? Where do we not get perf gain / where are we using std::vector still for shapes and dtypes?

I made some experiments replacing more std::vector with SmallVector:

• replacing op args like std::vector<int> axes to SmallVector.
• replacing all std::vector<array> with SmallVector.

and none gave signs of performance gain or regression. Intuitively I think it is because when a std::vector is only allocated once and almost never copied, the cost of heap allocation is negligible. For shape/strides the story is different because they are frequently copied and resized in performance critical code paths.

Currently all shape/strides are using SmallVector, but some code needs to handle both std::vector and SmallVector because some kernel args like axes and padding are still stored in std::vector.

[awni]

Makes sense, thanks for the explanation!