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

folly::tape #2109

Closed

Conversation

DenisYaroshevskiy
Copy link
Contributor

Summary:
A better version of vector<vector> for some scenarios.
Can also be an ok vector<string> if not everything is small vectors

Basic usecase: building vector by pushing one element at a time, no reserve.

PushBackVecInts_20_0_15                                     1.28us   782.19K
PushBackTapeInts_20_0_15                                  317.49ns     3.15M

Constructing a vector of strings (20 strings). When everything is SSO, there is no point in tape. However, when we allocate, tape begins to win big.

ConstructVecSmallStrings_20_0_15                          122.31ns     8.18M
ConstructTapeSmallStrings_20_0_15                         129.04ns     7.75M
ConstructVecLargeStrings_20_16_32                         319.24ns     3.13M
ConstructTapeLargeStrings_20_16_32                        147.52ns     6.78M

Worst case scenario - 2 small strings. Overhead of tape makes this slower. We could tackle this but it requires very complicated code and so far, not the use case encountered.

ConstructVec2SmallStrings                                  20.95ns    47.74M
ConstructTape2SmallStrings                                 38.83ns    25.75M

Differential Revision: D52260714

Summary:
A better version of `vector<vector>` for some scenarios.
Can also be an ok `vector<string>` if not everything is small vectors


Basic usecase: building vector<vector> by pushing one element at a time, no reserve.
```
PushBackVecInts_20_0_15                                     1.28us   782.19K
PushBackTapeInts_20_0_15                                  317.49ns     3.15M
```

Constructing a vector of strings (20 strings). When  everything is SSO, there is no point in tape. However, when we allocate, tape begins to win big.

```
ConstructVecSmallStrings_20_0_15                          122.31ns     8.18M
ConstructTapeSmallStrings_20_0_15                         129.04ns     7.75M
ConstructVecLargeStrings_20_16_32                         319.24ns     3.13M
ConstructTapeLargeStrings_20_16_32                        147.52ns     6.78M
```

Worst case scenario - 2 small strings. Overhead of tape makes this slower. We could tackle this but it requires very complicated code and so far, not the use case encountered.
```
ConstructVec2SmallStrings                                  20.95ns    47.74M
ConstructTape2SmallStrings                                 38.83ns    25.75M
```

Differential Revision: D52260714
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52260714

@facebook-github-bot
Copy link
Contributor

This pull request has been merged in b4ff536.

facebook-github-bot pushed a commit to facebook/hhvm that referenced this pull request Jan 2, 2024
Summary:
X-link: facebook/folly#2109

A better version of `vector<vector>` for some scenarios.
Can also be an ok `vector<string>` if not everything is small vectors

## Basic usecase 0: iteration for data, initially not in cache

```
IterateVecIntsCacheMiss_20_0_15                           449.93ns     2.22M
IterateTapeIntsCacheMiss_20_0_15                          352.49ns     2.84M
IterateVecStringsCacheMiss_20_0_15                        262.35ns     3.81M
IterateTapeStringsCacheMiss_20_0_15                       222.20ns     4.50M
```

Tape is more cache friendly, very packed and predictable.

## Basic usecase 1: building vector<vector> by pushing one element at a time, no reserve.
```
PushBackVecInts_20_0_15                                     1.28us   782.19K
PushBackTapeInts_20_0_15                                  317.49ns     3.15M
```

## Worst case - constructing from a known range of SSO strings

Constructing a vector of strings (20 strings). When  everything is SSO, there is no point in tape. However, when we allocate, tape begins to win big.

```
ConstructVecSmallStrings_20_0_15                          122.31ns     8.18M
ConstructTapeSmallStrings_20_0_15                         129.04ns     7.75M
ConstructVecLargeStrings_20_16_32                         319.24ns     3.13M
ConstructTapeLargeStrings_20_16_32                        147.52ns     6.78M
```

Worst case scenario - 2 small strings. Overhead of tape makes this slower. We could tackle this but it requires very complicated code and so far, not the use case encountered.
```
ConstructVec2SmallStrings                                  20.95ns    47.74M
ConstructTape2SmallStrings                                 38.83ns    25.75M
```

Reviewed By: dmm-fb

Differential Revision: D52260714

fbshipit-source-id: a90e01bc589646a38f2ca22c1b9589b6cd4c7f85
: g(minLen + maxLen), len(minLen, maxLen) {}

const Cont& operator()() {
buf.resize(len(g));
Copy link

Choose a reason for hiding this comment

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

@DenisYaroshevskiy shouldn't this be buf.reserve(len(g)); instead?

resize + emplace_back() will increase the size. While reserve will reserve the space and array won't grow dynamically as often.

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

Successfully merging this pull request may close these issues.

3 participants