diff options
| author | bors-servo <lbergstrom+bors@mozilla.com> | 2019-04-25 10:58:23 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-04-25 10:58:23 -0400 |
| commit | e877dc2759fd6f46abb3a841c6aa6e21ba1b8142 (patch) | |
| tree | ef6371d274e4b0538a6bf807e0ba72fc0b1c6f7c /components/script/dom/macros.rs | |
| parent | 07d1559141959cb0c49df33f1eb7dbc58c3e71da (diff) | |
| parent | 51d6b6350efd518fea1cf6f100e91fc9486ca30b (diff) | |
| download | servo-e877dc2759fd6f46abb3a841c6aa6e21ba1b8142.tar.gz servo-e877dc2759fd6f46abb3a841c6aa6e21ba1b8142.zip | |
Auto merge of #23263 - servo:rustup, r=jdm
Upgrade to rustc 1.36.0-nightly (e305df184 2019-04-24)
This includes a `size_of` regression for a few DOM types, due to https://github.com/rust-lang/rust/pull/58623 which replaces the implementation of `HashMap` in the standard library to Hashbrown.
Although `size_of<HashMap>` grows, it’s not obvious how total memory usage is going to be impacted: Hashbrown only has one `u8` instead of one `usize` of overhead per hash table bucket for storing (part of) a hash, and so might allocate less memory itself.
Hashbrown also typically has better run time performance: https://github.com/rust-lang/hashbrown#performance
Still, I’ve filed https://github.com/rust-lang/hashbrown/issues/69 about potentially reducing the `size_of<HashMap>` regression.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23263)
<!-- Reviewable:end -->
Diffstat (limited to 'components/script/dom/macros.rs')
0 files changed, 0 insertions, 0 deletions