Skip to content

Optimize ULEB decoding to improve MCCAS replay time #7952

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

Merged
merged 2 commits into from
Jan 12, 2024

Conversation

rastogishubham
Copy link

@rastogishubham rastogishubham commented Jan 10, 2024

MCCAS replay is slower than file based caching because it is DWARF aware. Part of parsing DWARF is decoding a lot of ULEBs. One way to quickly get the benefits is by replacing BinaryStreamReader with DataExtractor

With this patch we can see that on average MCCAS replay time went from between 15-16 seconds, to between 14 and 15 seconds.

ULEB unopt numbers:
Build Num, Median Replay Time
1, 16.362477000
2, 15.626469000
3, 15.794678000
4, 15.838866000
5, 15.691996000
6, 15.206883000
7, 16.119893000
8, 15.525278000
9, 16.549542000
10, 16.782434000

ULEB Opt Numbers:

Build Num, Median Replay Time
1, 15.498433000
2, 14.566443000
3, 14.720929000
4, 14.535185000
5, 14.107377000
6, 14.132124000
7, 14.922363000
8, 14.481217000
9, 14.866581000
10, 15.974748000

This function is not used anywhere and can be safely removed.
BinaryStreamReader and DataExtractor do similar things, but
BinaryStreamReader can also hold a buffer that is not contiguous which
comes with some performance penalties. Replacing it with DataExtractor
allows us to keep the same functionality but improve MCCAS replay time.
@rastogishubham rastogishubham changed the title Change BinaryStreamReader to DataExtractor Optimize ULEB reading to improve MCCAS replay time Jan 10, 2024
@rastogishubham rastogishubham changed the title Optimize ULEB reading to improve MCCAS replay time Optimize ULEB decoding to improve MCCAS replay time Jan 10, 2024
@rastogishubham rastogishubham marked this pull request as ready for review January 10, 2024 20:41
@rastogishubham
Copy link
Author

@swift-ci please test llvm

@rastogishubham rastogishubham requested review from felipepiovezan and adrian-prantl and removed request for felipepiovezan January 10, 2024 20:41
Copy link

@adrian-prantl adrian-prantl left a comment

Choose a reason for hiding this comment

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

LGTMgenerally, one question inline

uint64_t Data64;
if (auto Err = Reader.readULEB128(Data64))
handleAllErrors(std::move(Err));
DataExtractor Extractor(FormData, true, 8);

Choose a reason for hiding this comment

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

Do we know for sure that there will be 8 bytes available at all times?

Copy link
Author

Choose a reason for hiding this comment

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

That is just the address size, not how many bytes are available in the buffer

@rastogishubham rastogishubham merged commit 9b95a6e into swiftlang:next Jan 12, 2024
rastogishubham added a commit that referenced this pull request Jan 16, 2024
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.

3 participants