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

Avoid copying the contents of large platform message responses #4947

Merged
merged 1 commit into from
Apr 10, 2018

Conversation

jason-simmons
Copy link
Member

Assets are loaded via platform messages, and currently asset payloads are
being copied into Dart typed data buffers. This change uses external
typed data objects that wrap the existing buffer if copying would be
expensive.

See flutter/flutter#16291

@jason-simmons
Copy link
Member Author

Copy link
Contributor

@rmacnak-google rmacnak-google left a comment

Choose a reason for hiding this comment

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

lgtm

Copy link
Member

@chinmaygarde chinmaygarde left a comment

Choose a reason for hiding this comment

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

lgtm with a minor suggestion.

namespace {

// Avoid copying the contents of messages beyond a certain size.
const int kMessageCopyThreshold = 100;
Copy link
Member

Choose a reason for hiding this comment

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

How about making this one page sized instead?

Copy link
Member Author

Choose a reason for hiding this comment

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

This was based on measurement of the tradeoff between allocating (and later deleting) the new vector versus doing the memcpy.

@rmacnak-google do external objects have any additional performance cost compared to a standard TypedData?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, the size of the weak handle (~4 words) and the time for the GC to look at the weak handle table to see if they have been collected (a few dozen instructions). I'd expect it to pay off before one page, but even a high threshold here I think is fine because the bulk of the benefit comes from the very large messages.

Copy link
Member Author

Choose a reason for hiding this comment

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

Increased the threshold to 1000 bytes

@Hixie
Copy link
Contributor

Hixie commented Apr 10, 2018

This is great.

Assets are loaded via platform messages, and currently asset payloads are
being copied into Dart typed data buffers.  This change uses external
typed data objects that wrap the existing buffer if copying would be
expensive.

See flutter/flutter#16291
@chinmaygarde
Copy link
Member

@jason-simmons mentioned the other day that Dart allows modification of typed external data allocations. This would mean that Dart code could be in the middle of modifying the buffer when the engine is attempting to read from it (usually for image decompression). We should make sure those buffers are un-modifiable as mentioned in flutter/flutter#16291 before this patch makes it into an engine roll.

@jason-simmons
Copy link
Member Author

The buffer in the std::vector given to WrapByteData is a copy - it isn't the original buffer returned by the raw resource access API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants