Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MB-60400: Do not walk document if vector is processed successfully #1984

Merged
merged 1 commit into from
Feb 12, 2024

Conversation

CascadingRadium
Copy link
Member

  • Currently, the walkDocument function is called after processing every vector, regardless of whether the vector was processed successfully or not. This results in the execution of the following code:

      for i := 0; i < val.Len(); i++ {
      	if val.Index(i).CanInterface() {
      		fieldVal := val.Index(i).Interface()
      		dm.processProperty(fieldVal, path, append(indexes, uint64(i)), context)
      	}
      }
    
  • In this code, val.Len() will be equal to the dimension of the vector, which could potentially be very high (up to 2048). For each iteration of the loop, processProperty() is called on each float value extracted from the vector. Within processProperty(), it attempts to add a numeric field and creates a new array using append().

  • If the property has already been successfully processed as a vector, then each individual float value within the vector cannot be processed as a separate numeric field. This is because the same path variable is passed, ensuring that the fieldMapping will always be of type vector, not number.

  • The check introduced here ensures that if the vector is successfully processed and a vector field is added, we skip calling walkDocument on it.

  • This assertion is supported by the memory profiles obtained while indexing 1528-dimensional vectors, where approximately 65 GB (8% of the total allocated space) was dedicated to this process. The check introduced here allows us to avoid such excessive allocation.

@abhinavdangeti abhinavdangeti merged commit 3546ac3 into unstable Feb 12, 2024
9 checks passed
@abhinavdangeti abhinavdangeti deleted the garbage3 branch February 12, 2024 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants