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

subscriber: update sharded-slab, pool hashmaps #1064

Merged
merged 3 commits into from
Oct 22, 2020
Merged

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Oct 22, 2020

This backports #1062 to v0.1.6. This has already been approved on
master.

hawkw/sharded-slab#45 changes sharded-slab so that the per-shard
metadata is allocated only when a new shard is created, rather than all
up front when the slab is created. This fixes the very large amount of
memory allocated by simply creating a new Registry without actually
collecting any traces.

This branch updates tracing-subscriber to depend on sharded-slab
0.1.0, which includes the upstream fix.

In addition, this branch the registry from using sharded_slab::Slab to
sharded_slab::Pool. This allows us to clear hashmap allocations for
extensions in-place, retaining the already allocated maps. This should
improve new_span performance a bit.

Fixes #1005

Signed-off-by: Eliza Weisman eliza@buoyant.io

This backports #1062 to v0.1.6. This has already been approved on
master.

hawkw/sharded-slab#45 changes `sharded-slab` so that the per-shard
metadata is allocated only when a new shard is created, rather than all
up front when the slab is created. This fixes the very large amount of
memory allocated by simply creating a new `Registry` without actually
collecting any traces.

This branch updates `tracing-subscriber` to depend on `sharded-slab`
0.1.0, which includes the upstream fix.

In addition, this branch the registry from using `sharded_slab::Slab` to
`sharded_slab::Pool`. This allows us to clear hashmap allocations for
extensions in-place, retaining the already allocated maps. This should
improve `new_span` performance a bit.

Fixes #1005

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@hawkw hawkw requested a review from a team as a code owner October 22, 2020 22:18
hawkw added 2 commits October 22, 2020 15:28
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@hawkw hawkw merged commit a6e7d5e into v0.1.x Oct 22, 2020
hawkw added a commit that referenced this pull request Oct 22, 2020
Fixed

- **registry**: Fixed `Registry::new` allocating an excessively large
  amount of memory, most of which would never be used ([#1064])

Changed

- **registry**: Improved `new_span` performance by reusing `HashMap`
  allocations for `Extensions` ([#1064])
- **registry**: Significantly improved the performance of
  `Registry::enter` and `Registry::exit` ([#1058])

[#1064]: #1064
[#1058]: #1058
hawkw added a commit that referenced this pull request Oct 22, 2020
Fixed

- **registry**: Fixed `Registry::new` allocating an excessively large
  amount of memory, most of which would never be used ([#1064])

Changed

- **registry**: Improved `new_span` performance by reusing `HashMap`
  allocations for `Extensions` ([#1064])
- **registry**: Significantly improved the performance of
  `Registry::enter` and `Registry::exit` ([#1058])

[#1064]: #1064
[#1058]: #1058
hawkw added a commit to linkerd/linkerd2-proxy that referenced this pull request Oct 22, 2020
This picks up the following upstream changes:

* tokio-rs/tracing#1064, which fixes a bug where creating a subscriber
  would allocate a large amount of memory that was not actually used

* tokio-rs/tracing#1058, which significantly reduces the overhead of
  entering and exiting spans

Together, these changes should improve proxy performance when tracing is
enabled.
olix0r pushed a commit to linkerd/linkerd2-proxy that referenced this pull request Oct 23, 2020
This picks up the following upstream changes:

* tokio-rs/tracing#1064, which fixes a bug where creating a subscriber
  would allocate a large amount of memory that was not actually used

* tokio-rs/tracing#1058, which significantly reduces the overhead of
  entering and exiting spans

Together, these changes should improve proxy performance when tracing is
enabled.
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
This backports tokio-rs#1062 to v0.1.6. This has already been approved on
master.

hawkw/sharded-slab#45 changes `sharded-slab` so that the per-shard
metadata is allocated only when a new shard is created, rather than all
up front when the slab is created. This fixes the very large amount of
memory allocated by simply creating a new `Registry` without actually
collecting any traces.

This branch updates `tracing-subscriber` to depend on `sharded-slab`
0.1.0, which includes the upstream fix.

In addition, this branch the registry from using `sharded_slab::Slab` to
`sharded_slab::Pool`. This allows us to clear hashmap allocations for
extensions in-place, retaining the already allocated maps. This should
improve `new_span` performance a bit.

Fixes tokio-rs#1005

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
Fixed

- **registry**: Fixed `Registry::new` allocating an excessively large
  amount of memory, most of which would never be used ([tokio-rs#1064])

Changed

- **registry**: Improved `new_span` performance by reusing `HashMap`
  allocations for `Extensions` ([tokio-rs#1064])
- **registry**: Significantly improved the performance of
  `Registry::enter` and `Registry::exit` ([tokio-rs#1058])

[tokio-rs#1064]: tokio-rs#1064
[tokio-rs#1058]: tokio-rs#1058
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.

1 participant