Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@zljj0818
Copy link
Contributor

@zljj0818 zljj0818 commented Jun 4, 2020

std::vector<uint8_t> data(mapping->GetSize()) consume much time to initialize large arrary

@fluttergithubbot
Copy link
Contributor

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

1 similar comment
@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@zljj0818
Copy link
Contributor Author

zljj0818 commented Jun 4, 2020

@googlebot I signed it!

@zljj0818
Copy link
Contributor Author

zljj0818 commented Jun 4, 2020

@liyuqian I had signed CLA, why cla/google always failed?

@liyuqian
Copy link
Contributor

liyuqian commented Jun 4, 2020

It's probably because of an email address mismatch. Your commit has an author email of "[email protected]". Can you please double check that's email signed the CLA? If not, you can change your commit email: https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address

@liyuqian liyuqian added perf: speed Performance issues related to (mostly rendering) speed severe: performance Relates to speed or footprint issues. labels Jun 4, 2020
@liyuqian liyuqian requested a review from jason-simmons June 4, 2020 22:27
Copy link
Contributor

@liyuqian liyuqian left a comment

Choose a reason for hiding this comment

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

It would be nice to add a microbenchmark to test PlatformMessageResponseDart with a 3MB asset. See, e.g., the benchmark in https://github.com/flutter/engine/blob/master/shell/common/shell_benchmarks.cc

Dart_TypedData_kByteData, heap_data->data(), heap_data->size(),
heap_data, heap_data->size(), MessageDataFinalizer);
void* data = malloc(size);
memset(data, 0, size);
Copy link
Contributor

Choose a reason for hiding this comment

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

The memset seems to be unnecessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It would be nice to add a microbenchmark to test PlatformMessageResponseDart with a 3MB asset. See, e.g., the benchmark in https://github.com/flutter/engine/blob/master/shell/common/shell_benchmarks.cc

PlatformMessageResponseDart only post a ui task, and this ui task will consume time when execute

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The memset seems to be unnecessary?

Yes, just according to the logical of std::vector

if (data.size() < kMessageCopyThreshold) {
Dart_Handle WrapByteData(std::unique_ptr<fml::Mapping> mapping) {
size_t size = mapping->GetSize();
if (size < kMessageCopyThreshold) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This if branch is unnecessary as we're always calling memcpy: whether inside ToByteData, or inside the else branch, or inside the old WrapByteData(std::unique_ptr<fml::Mapping> mapping) function.

// Avoid copying the contents of messages beyond a certain size.
const int kMessageCopyThreshold = 1000;

class DataWrapper {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this DataWrapper would be unnecessary if we just use ToByteData's implementation inside WrapByteData:

Dart_Handle WrapByteData(std::unique_ptr<fml::Mapping> mapping) {
  Dart_Handle data_handle =
      Dart_NewTypedData(Dart_TypedData_kByteData, mapping->GetSize());
  if (Dart_IsError(data_handle))
    return data_handle;

  Dart_TypedData_Type type;
  void* data = nullptr;
  intptr_t num_bytes = 0;
  FML_CHECK(!Dart_IsError(
      Dart_TypedDataAcquireData(data_handle, &type, &data, &num_bytes)));

  memcpy(data, buffer.data(), num_bytes);
  Dart_TypedDataReleaseData(data_handle);
  return data_handle;
}

Copy link
Contributor Author

@zljj0818 zljj0818 Jun 4, 2020

Choose a reason for hiding this comment

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

I intend to optimze according to orignal code. The origial code if if (data.size() < kMessageCopyThreshold) , it will use dart vm heap to allocate data, else it use application heap to alloate data, dart vm only use DataWrapper pointer.
If use ToByteData will consume more dart vm heap.

@jason-simmons
Copy link
Member

The platform message Dart ByteData objects can be allocated with the Tonic library that the engine uses to wrap the Dart API.

I've created a proposed PR: #18838

The version of WrapByteData within PlatformMessageResponseDart that takes a std::vector dates back to an older implementation of PlatformMessageResponseDart::Complete where the message was held in a std::vector. That version of WrapByteData would transfer the vector's buffer over to a Dart external typed data object without copying.

Later PlatformMessageResponseDart::Complete was changed to provide the message as an fml::Mapping. The fml::Mapping data must always be copied into a buffer whose lifetime is controlled by Dart. Thus WrapByteData is obsolete and can be replaced by tonic::DartByteData::Create.

@zljj0818
Copy link
Contributor Author

zljj0818 commented Jun 5, 2020

ok, but it will use more dart vm heap?

@jason-simmons
Copy link
Member

#18838 will allocate small objects on the Dart VM heap and will use a malloc buffer for large objects. This appears to be the best performance tradeoff given how Dart implements Dart_NewTypedData and Dart_NewExternalTypedData.

@zljj0818
Copy link
Contributor Author

zljj0818 commented Jun 5, 2020

ok, close this PR

@zljj0818 zljj0818 closed this Jun 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla: no perf: speed Performance issues related to (mostly rendering) speed severe: performance Relates to speed or footprint issues.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants