Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
http://www.robohornet.org gives a score of 101.36 on master,
and 102.68 with this PR. The latter is slightly better,
but probably within noise level.
So it looks like this PR does not affect DOM performance.
This is expected since `Box::new` is defined as:
```rust
impl<T> Box<T> {
#[inline(always)]
pub fn new(x: T) -> Box<T> {
box x
}
}
```
With inlining, it should compile to the same as box syntax.
This introduces DeclarationSource, to see if a declaration has been parsed or
set from CSSOM in a declaration block.
The Servo_DeclarationBlock_SetFoo and similar callers are changed to
DeclarationSource::CssOm because their semantics are more CSSOM-y, but it
shouldn't matter since they should all be checked before hand with
Servo_DeclarationBlock_PropertyIsSet.
In a later PR, DomRoot<T> will become a type alias of Root<Dom<T>>,
where Root<T> will be able to handle all the things that need to be
rooted that have a stable traceable address that doesn't move for the
whole lifetime of the root. Stay tuned.
The alias is left there temporarilly and will be removed completely in a later commit where
also components/style/gecko/generated/structs_{debug|release}.rs are re-generated (they still
use the old alias).
We parse when assigning using the namespaces of the stylesheet. It isn't
clear if the spec says to do that (Firefox doesn't support the setter at
all, Chrome does, Safari doesn't); the spec issue is here:
https://github.com/w3c/csswg-drafts/issues/1511
Also fix ToCss implementation of AttrSelectorOperator to not pad with
spaces, to conform with CSSOM. This means we have to update some unit
tests that expect operators with spaces around them in attribute
selectors to roundtrip.
See the "attribute selector" section of "Serializing Selectors" here:
https://drafts.csswg.org/cssom/#serializing-selectors
CSSStyleRule.selectorText is specified here:
https://drafts.csswg.org/cssom/#dom-cssstylerule-selectortext
This enum type used to contain the result of parsing
one CSS source declaration (`name: value;`) and expanding shorthands.
Enum types are as big as the biggest of their variant (plus discriminant),
which was quite big because some shorthands
expand to many longhand properties.
This type was returned through many functions and methods,
wrapped and rewrapped in `Result` with different error types.
This presumably caused significant `memmove` traffic.
Instead, we now allocate an `ArrayVec` on the stack
and pass `&mut` references to it for various functions to push into it.
This type is also very big, but we never move it.
We still use an intermediate data structure because we sometimes decide
after shorthand expansion that a declaration is invalid after all
and that we’re gonna drop it.
Only later do we push to a `PropertyDeclarationBlock`,
with an entire `ArrayVec` or nothing.
In future work we can try to avoid a large stack-allocated array,
and instead writing directly to the heap allocation
of the `Vec` inside `PropertyDeclarationBlock`.
However this is tricky:
we need to preserve this "all or nothing" aspect
of parsing one source declaration,
and at the same time we want to make it as little error-prone as possible
for the various call sites.
`PropertyDeclarationBlock` curently does property deduplication
incrementally: as each `PropertyDeclaration` is pushed,
we check if an existing declaration of the same property exists
and if so overwrite it.
To get rid of the stack allocated array we’d need to somehow
deduplicate separately after pushing multiple `PropertyDeclaration`.
We need another flag that represents allow-negative-number for SMIL, so
this enum will also comprise the another parsing mode that allows negative number.
Styling was correct because of the explicit dirtiness, but still not fun.
Some things, like dynamic updates to with things like [style~="color"] ~ foo
selectors, were pretty broken, because we didn't take snapshots of those
attributes.
* `LonghandId` and `ShorthandId` are C-like enums
* `Atom` is used for the name of custom properties.
* `PropertyDeclarationId` is the identifier for `PropertyDeclaration`,
after parsing and shorthand expansion. (Longhand or custom property.)
* `PropertyId` represents any CSS property, e.g. in CSSOM.
(Longhand, shorthand, or custom.)
Using these instead of strings avoids some memory allocations and copies.
