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

perf(storage): remove protobuf's copy of data on unmarshalling #9526

Merged
merged 13 commits into from Mar 19, 2024

Conversation

BrennaEpp
Copy link
Contributor

@BrennaEpp BrennaEpp commented Mar 8, 2024

  • This reduces CPU usage and improves performance when running concurrent reads, since it avoids an extra copy of the data at the protobuf layer since it will unmarshal the data (which is already in a contiguous buffer in the message we receive) into another buffer. We do not need both buffers, so we can return the appropriate address in the buffer rather than copying it into another buffer to return. This is not supported by the proto library today, so we have to manually decode the message buffer.
  • Tested performance and cpu usage in VM for large (100MB) and medium file (2MB) reads. The proto unmarshalling portion of cpu usage is no longer sampled (does not show up in the flame graphs).
  • Passes unit and integration tests; still needs to be tested for retries

Note that this could be made even more efficient by parsing the whole block at once instead of reusing the readProtoBytes function, which will look at and then skip over the fields that have already been parsed. readProtoBytes calls protowire functions that do some calculations that re-slice the data buffer, without any copies. So, I don't think the improvement would be noticeable, especially since we only have 4 fields in the message. The cpu flame graphs do not show this function, so whatever time is spent there seems to be negligible.

cc: @dfawley

@BrennaEpp BrennaEpp requested review from a team as code owners March 8, 2024 09:32
@product-auto-label product-auto-label bot added size: m Pull request size is medium. api: storage Issues related to the Cloud Storage API. labels Mar 8, 2024
@BrennaEpp BrennaEpp changed the title draft(storage): remove protobuf copy of data draft(storage): remove protobuf's copy of data on unmarshalling Mar 9, 2024
Copy link
Contributor

@tritone tritone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good; just a few minor suggestions and questions

storage/grpc_client.go Outdated Show resolved Hide resolved
storage/grpc_client.go Outdated Show resolved Hide resolved
storage/grpc_client.go Outdated Show resolved Hide resolved
storage/integration_test.go Show resolved Hide resolved
storage/grpc_client.go Outdated Show resolved Hide resolved
storage/grpc_client.go Show resolved Hide resolved
storage/grpc_client.go Outdated Show resolved Hide resolved
storage/grpc_client.go Outdated Show resolved Hide resolved
storage/grpc_client.go Outdated Show resolved Hide resolved
@BrennaEpp BrennaEpp changed the title draft(storage): remove protobuf's copy of data on unmarshalling perf(storage): remove protobuf's copy of data on unmarshalling Mar 12, 2024
@BrennaEpp BrennaEpp requested a review from tritone March 14, 2024 01:04
Copy link
Contributor

@tritone tritone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, nice work!

storage/grpc_client.go Outdated Show resolved Hide resolved
storage/grpc_client.go Show resolved Hide resolved
storage/grpc_client_test.go Show resolved Hide resolved
// wire-encoded message buffer b, or an error if the message is invalid.
// This is used on the first recv of an object as it may contain all fields of
// ReadObjectResponse.
func readFullObjectResponse(b []byte) (*storagepb.ReadObjectResponse, error) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might want to note that this function is essentially identical to proto.Unmarshal, except it aliases the data in the input []byte. If we ever add a feature to Unmarshal that does that, this function can be dropped.

}
}

// Unmarshal remaining fields.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're unmarshaling all the fields in the message, so this will be a bit more efficient if you loop once over the fields rather than looking up each individually:

off := 0
for off < len(b) {
  num, typ, n := protowire.ConsumeTag(b[off:])
  if n < 0 {
    return nil, protowire.ParseError(n)
  }
  off += n
  switch {
  case num == checksummedDataField && typ == protowire.BytesType:
    // unmarshal the checksummed_data field
  case num == objectChecksumsField && typ == protowire.BytesType:
    // unmarshal the object_checksums field
  case num == contentRangeField && typ == protowire.BytesType:
    // unmarshal the content_range field
  case num == metadataField && typ == protowire.BytesType:
    // unmarshal the metadata field
  default:
    n = protowire.ConsumeFieldValue(num, typ, b[off:])
    if n < 0 {
      return nil, protowire.ParseError(n)
    }
    off += n
  }
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestion!

@BrennaEpp BrennaEpp merged commit 81281c0 into googleapis:main Mar 19, 2024
11 checks passed
gcf-merge-on-green bot pushed a commit that referenced this pull request Mar 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: storage Issues related to the Cloud Storage API. size: m Pull request size is medium.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants