refactor: optimization on stacking#1016
Conversation
Signed-off-by: Sami Jaghouar <[email protected]>
Signed-off-by: Sami Jaghouar <[email protected]>
Signed-off-by: Sami Jaghouar <[email protected]>
JohannesMessner
left a comment
There was a problem hiding this comment.
LGTM, but did we make sure that this is equivalent to torch.stack() with no unintended consequnces?
Signed-off-by: Sami Jaghouar <[email protected]>
Signed-off-by: Sami Jaghouar <[email protected]>
I am not sure to understand the question. What "this" refer to here ? |
We talked about this on the other PR; "this" being the technique where we pre-allocate a tensor of desired shape and then set slices of it iteratively. I just want to make sure that that doesn't do anything funky in terms of runtime/memory that |
okay now I remember, unfortunately https://discuss.pytorch.org/t/what-is-happening-under-the-hood-when-calling-torch-stack/170105 nobody responded to me on pytorch forums. Though I checked it looks like it is doing the same, and from my understanding it should do the same |
Okay then! |
Signed-off-by: Sami Jaghouar <[email protected]>
|
📝 Docs are deployed on https://ft-refactor-optimization-stack--jina-docs.netlify.app 🎉 |
Context
We recently introduced some refactoring on DocumentArrayStacked : #1008 which change a little bit the way we handled the stacking (We removed any state where the document does not hold the data but instead some time its hold a view of the data that has been moved to the column)
As noticed by @JohannesMessner this new way of stacking could be optimized because once the data has been stacked we re traverse the DocumentArray to put the view from the column to the document.
Originally posted by @samsja in #1008 (comment) there is room for improvements.
We could:
What this PR do: