tawasuyu/taffy

* 0.2 release notes WIP

* Deindent list items in release notes

* Add benchmark results

* Add yoga benchmarks to README

* Add yoga and taffy 0.1 vs 0.2 benchmarks to release notes

* Reorganise release note headings

* Misc release notes updates

* Fix markdown lints

* Grammar nit

* Remove references to FlexboxLayout from release notes

* Spelling

* Fill in release notes section on AvailableSpace enum

* Add release notes section on `mark_dirty` change

* Cleanup 0.2 release notes

* Fix markdown lints

* Remove mark_dirty from the release notes as the change has been reverted

* Fix table heading

Co-authored-by: Andreas Weibye <13300393+Weibye@users.noreply.github.com>

* Remove % change heading from table that doesn't actually have that column

* s/below/above/

* Add note about removed deps to changelog

* Add cargo-vendor fix to release notes

* Separate the correctness fixes from the vendor fix in RELEASES.md

Co-authored-by: TimJentzsch <tim-jentzsch@gmx.de>

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Andreas Weibye <13300393+Weibye@users.noreply.github.com>
Co-authored-by: TimJentzsch <tim-jentzsch@gmx.de>

diff --git a/README.md b/README.md
index 1b6f3df63..d6e8cb8d0 100644
--- a/README.md
+++ b/README.md
@@ -66,6 +66,24 @@ assert_eq!(taffy.layout(body_node).unwrap().size.height, 500.0); // This value w
 
 ```
 
+## Benchmarks (vs. [Yoga](https://github.com/facebook/yoga))
+
+- Run on a 2021 MacBook Pro with M1 Pro processor.
+- Taffy benchmarks are using criterion (10 iterations).
+- Yoga benchmarks run via it's node.js bindings (the `yoga-layout-prebuilt` npm package), they were run a few times manually and it was verified that variance in the numbers of each run was minimal. It should be noted that this is using an old version of Yoga.
+
+(note that the table below contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))
+
+| Benchmark | Yoga | Taffy 0.2 |
+| --- | --- | --- |
+| yoga/10 nodes (1-level hierarchy) | 45.1670 µs | 33.297 ns |
+| yoga/100 nodes (2-level hierarchy) | 134.1250 µs | 336.53 ns |
+| yoga/1_000 nodes (3-level hierarchy) | 1.2221 ms | 3.8928 µs |
+| yoga/10_000 nodes (4-level hierarchy) | 13.8672 ms | 36.162 µs |
+| yoga/100_000 nodes (5-level hierarchy) | 141.5307 ms | 1.6404 ms |
+
+Most popular websites seem to have between 3,000 and 10,000 nodes (although they also require text layout, which neither yoga nor taffy implement).
+
 ## Contributions
 
 [Contributions welcome](https://github.com/DioxusLabs/taffy/blob/main/CONTRIBUTING.md):
diff --git a/RELEASES.md b/RELEASES.md
index 3cfa44e8a..577c33eee 100644
--- a/RELEASES.md
+++ b/RELEASES.md
@@ -2,53 +2,129 @@
 
 ## 0.2.0
 
-### 0.2.0 Added
+### New features
 
-- Added `taffy::error::InvalidChild` Error type
-- `taffy::node::Taffy.new_leaf()` which allows the creation of new leaf-nodes without having to supply a measure function
-- Builder methods are now `const` where possible
-  - Several convenience constants have been defined: notably `FlexboxLayout::DEFAULT`
-- New `Layout` convenience constructor: `with_order(order: u32)`
-- Added support for `AlignContent::SpaceEvenly`
-- Added `AvailableSpace` enum
-- Added `debug` modules with a `print_tree` function, which prints a debug representation of the computed layout for a tree of nodes.
-- Added support for `gap` property (shorthand form of `row-gap`/`column-gap`)
+#### Flexbox "gap" and `AlignContent::SpaceEvenly`
 
-### 0.2.0 Changed
+The [gap](https://developer.mozilla.org/en-US/docs/Web/CSS/gap) property is now supported on flex containers. This can make it much easier to create even spacing or "gutters" between nodes.
 
+Additionally we have a `SpaceEvenly` variant to the `AlignContent` enum to support evenly spaced justification in the cross axis (equivalent to  `align-content: space-evenly` in CSS)
+
+#### Debug module and cargo feature
+
+Two debugging features have been added:
+
+- `taffy::debug::print_tree(&Taffy, root)` - This will print a debug representation of the computed layout of an entire node tree (starting at `root`), which can be useful for debugging layouts.
+
+- A cargo feature `debug`. This enabled debug logging of the layout computation process itself (this is probably mainly useful for those working taffy itself).
+
+### Performance improvements
+
+A number of performance improvements have landed since taffy 0.1:
+
+- Firstly, our custom `taffy::forest` storage implementation was ripped out and replaced with a much simpler implementation using the `slotmap` crate. This led to performance increases of up to 90%.
+- Secondly, the caching implementation was improved by upping the number of cache slots from 2 to 4 and tweaking how computed results are allocated to chache slots to better match the actual usage patterns of the flexbox layout algorithm. This had a particularly dramatic effect on deep hierachies (which often involve recomputing the same results repeatedly), fixing the exponential blowup that was previously exhibited on these trees and improving performance by over 1000x in some cases!
+
+#### Benchmarks vs. Taffy 0.1
+
+| Benchmark | Taffy 0.1 | Taffy 0.2 | % change (0.1 -> 0.2) |
+| --- | --- | --- | --- |
+| wide/1_000 nodes (2-level hierarchy) | 3.5458 µs | 4.3571 µs | +23.333% |
+| wide/10_000 nodes (2-level hierarchy) | 36.418 µs | 42.967 µs | +17.357% |
+| wide/100_000 nodes (2-level hierarchy) | 1.8275 ms | 3.9096 ms | +112.26% |
+| deep/4000 nodes (12-level hierarchy)) | 5.1845 s | 15.318 µs | -100.000% |
+| deep/10_000 nodes (14-level hierarchy) | 75.978 s | 40.315 µs | -100.000% |
+| deep/100_000 nodes (17-level hierarchy) | - | 2.7644 ms| - |
+| deep/1_000_000 nodes (20-level hierarchy) | - | 1.2130 s| - |
+
+(note that the table above contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))
+
+As you can see, we have actually regressed slightly in the "wide" benchmarks (where all nodes are siblings of a single parent node). Although it should be noted our results in these benchmarks are still very fast, especially on the 10,000 node benchmark which we consider to be the most realistic size where the result is measured in microseconds.
+
+However, in the "deep" benchmarks we see dramatic improvements. The previous version of Taffy suffered from exponential blowup in the case of deeply nested hierachies. This has resulted in somewhat silly improvements like the 10,000 node (14-level) hierachy where Taffy 0.2 is a full 1 million times faster than Taffy 0.1. We've also included results with larger numbers of nodes (although you're unlikely to need that many) to demonstrate that this scalability continues up to even deeper levels of nesting.
+
+#### Benchmarks vs. [Yoga](https://github.com/facebook/yoga))
+
+Yoga benchmarks run via it's node.js bindings (the `yoga-layout-prebuilt` npm package), they were run a few times manually and it was verified that variance in the numbers of each run was minimal. It should be noted that this is using an old version of Yoga.
+
+| Benchmark | Yoga | Taffy 0.2 |
+| --- | --- | --- |
+| yoga/10 nodes (1-level hierarchy) | 45.1670 µs | 33.297 ns |
+| yoga/100 nodes (2-level hierarchy) | 134.1250 µs | 336.53 ns |
+| yoga/1_000 nodes (3-level hierarchy) | 1.2221 ms | 3.8928 µs |
+| yoga/10_000 nodes (4-level hierarchy) | 13.8672 ms | 36.162 µs |
+| yoga/100_000 nodes (5-level hierarchy) | 141.5307 ms | 1.6404 ms |
+
+(note that the table above contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))
+
+While we're trying not to get too excited (there could easily be an issue with our benchmarking methodology which make this an unfair comparison), we are pleased to see that we seem to be anywhere between 100x and 1000x times faster depending on the node count!
+
+### Breaking API changes
+
+#### Node creation changes
+
+- `taffy::Node` is now unique only to the Taffy instance from which it was created.
+- Renamed `Taffy.new_node(..)` -> `Taffy.new_with_children(..)`
+- Renamed `Taffy.new_leaf()` -> `Taffy.new_leaf_with_measure()`
+- Added `taffy::node::Taffy.new_leaf()` which allows the creation of new leaf-nodes without having to supply a measure function
+
+#### Error handling/representation improvements
+
+- Renamed `taffy::Error` -> `taffy::error::TaffyError`
+- Replaced `taffy::error::InvalidChild` with a new `InvalidChild` variant of `taffy::error::TaffyError`
+- Replaced `taffy::error::InvalidNode` with a new `InvalidNode` variant of `taffy::error::TaffyError`
+- The following method new return `Err(TaffyError::ChildIndexOutOfBounds)` instead of panicking:
+  - `taffy::Taffy::remove_child_at_index`
+  - `taffy::Taffy::replace_child_at_index`
+  - `taffy::Taffy::child_at_index`
+- `Taffy::remove` now returns a `Result<usize, Error>`, to indicate if the operation was sucessful (and if it was, which ID was invalidated).
+
+#### Some uses of `Option<f32>` replaced with a new `AvailableSpace` enum
+
+A new enum `Taffy::layout::AvailableSpace` has been added.
+
+The definition looks like this:
+
+```rust
+/// The amount of space available to a node in a given axis
+pub enum AvailableSpace {
+    /// The amount of space available is the specified number of pixels
+    Definite(f32),
+    /// The amount of space available is indefinite and the node should be laid out under a min-content constraint
+    MinContent,
+    /// The amount of space available is indefinite and the node should be laid out under a max-content constraint
+    MaxContent,
+}
+```
+
+This enum is now used instead of `Option<f32>` when calling `Taffy.compute_layout` (if you previously passing `Size::NONE` to `compute_layout`, then you will need to change this to `Size::MAX_CONTENT`).
+
+And a different instance of it is passed as a new second parameter to `MeasureFunc`. `MeasureFunc`s may choose to use this parameter in their computation or ignore it as they see fit. The canonical example of when it makes sense to use it is when laying out text. If `MinContent` has been passed in the axis in which the text is flowing (i.e. the horizontal axis for left-to-right text), then you should line-break at every possible opportunity (e.g. all word boundaries), whereas if `MaxContent` has been passed then you shouldn't line break at all..
+
+#### Builder methods are now `const` where possible
+
+- Several convenience constants have been defined: notably `Style::DEFAULT`
 - `Size<f32>.zero()` is now `Size::<f32>::ZERO`
 - `Point<f32>.zero()` is now  `Point::<f32>::ZERO`
-- renamed `taffy::node::Taffy.new_leaf()` -> `taffy::node::Taffy.new_leaf_with_measure()`
-- removed the public `Number` type; a more idiomatic `Option<f32>` is used instead
+- `Size::undefined()` is now `Size::NONE`
+
+#### Removals
+
+- Removed `taffy::forest::Forest`. `taffy::node::Taffy` now handles it's own storage using a slotmap (which comes with a performance boost up to 90%).
+- Removed `taffy::number::Number`. Use `Option<f32>` is used instead
   - the associated public `MinMax` and `OrElse` traits have also been removed; these should never have been public
-- `Sprawl::remove` now returns a `Result<usize, Error>`, to indicate if the operation was sucessful, and if it was, which ID was invalidated.
-- renamed `taffy::forest::Forest.new-node(..)` `taffy::forest::Forest.new_with_children(..)`
-- renamed `taffy::node::Taffy.new-node(..)` -> `taffy::node::Taffy.new_with_children(..)`
-- renamed `taffy::style::Style` -> `taffy::style::FlexboxLayout` to more precicely indicate its purpose
-- renamed `taffy::Error` -> `taffy::error::TaffyError`
-- `taffy::Taffy::remove_child_at_index`, `taffy::Taffy::replace_child_at_index`, and `taffy::Taffy::child_at_index` now return `taffy::InvalidChild::ChildIndexOutOfBounds` instead of panicing
-- `taffy::Node` is now unique only to the Taffy instance from which it was created.
-- `taffy::error::InvalidChild` is now `taffy::error::TaffyError`
-- `taffy::error::InvalidNode` has been removed and is now just a branch on the `TaffyError` enum
-- `taffy::forest::Forest` has been merged into `taffy::node::Taffy` for a performance boost up to 90%
-- `Size::undefined()` has been removed, use `Size::NONE` instead.
-- `Taffy.compute_layout()` now takes `Size<AvailableSpace>` instead of `Size<Option<f32>>`. If you were previously passing `Size::NONE` to this function, you will now need to pass `Size::MAX_CONTENT`
-- Measure functions now have an additional `available_space` parameter which indicates the size of the parent or a min/max-content sizing constraint.
-- Added `Size::MIN_CONTENT` and `Size::MAX_CONTENT` constants. In many cases, you will want to replace `Size::NONE` with `Size::MAX_CONTENT`.
-
-### 0.2.0 Fixed
-
-- Performance with deep hierarchies is greatly improved. It is now comparable to that of shallow hierarchies with the same number of nodes.
-- nodes can only ever have one parent
-- fixed rounding of fractional values to follow latest Chrome - values are now rounded the same regardless of their position
-- fixed computing free space when using both `flex-grow` and a minimum size
-- padding is now only subtracted when determining the available space if the node size is unspecified, following [section 9.2.2 of the flexbox spec](https://www.w3.org/TR/css-flexbox-1/#line-sizing)
-- `MeasureFunc` (and hence `NodeData` and hence `Forest` and hence the public `Taffy` type) are now `Send` and `Sync`, enabling their use in async and parallel applications
-
-### 0.2.0 Removed
-
-- various internal types are no longer public
-  - if you needed one of these, please file an issue!
+- Removed unused dependencies `hashbrown`, `hash32`, and `typenum`. `slotmap` is now the only required dependency (`num_traits` and `arrayvec` are also required if you wish to use taffy in a `no_std` environment).
+
+### Fixes
+
+- Miscellaneous correctness fixes which align our implementation with Chrome:
+
+  - Nodes can only ever have one parent
+  - Fixed rounding of fractional values to follow latest Chrome - values are now rounded the same regardless of their position
+  - Fixed computing free space when using both `flex-grow` and a minimum size
+  - Padding is now only subtracted when determining the available space if the node size is unspecified, following [section 9.2.2 of the flexbox spec](https://www.w3.org/TR/css-flexbox-1/#line-sizing)
+  - `MeasureFunc` (and hence `NodeData` and hence `Forest` and hence the public `Taffy` type) are now `Send` and `Sync`, enabling their use in async and parallel applications
+- Taffy can now be vendored using `cargo-vendor` (README.md is now included in package).
 
 ## 0.1.0
 
diff --git a/benches/results-2022-11-23.md b/benches/results-2022-11-23.md
new file mode 100644
index 000000000..b00cff9fe
--- /dev/null
+++ b/benches/results-2022-11-23.md
@@ -0,0 +1,29 @@
+# Benchmarks (Taffy 0.2 vs Taffy 0.1 and Yoga)
+
+- Using [this branch](https://github.com/nicoburns/taffy/tree/0.1-benchmarks) that backports the new benchmarks to the `0.1` tag.
+- Run on a 2021 MacBook Pro with M1 Pro processor.
+- Taffy benchmarks are using criterion (10 iterations).
+- Yoga benchmarks run via the `yoga-layout-prebuilt` npm package, they were run a few times manually and it was verified that variance in the numbers of each run was minimal. It should be noted that this is using an old version of Yoga.
+
+| Benchmark | Yoga | Taffy 0.1 | Taffy 0.2 | % change (0.1 -> 0.2) |
+| --- | --- | --- | --- | --- |
+| yoga/10 nodes (1-level hierarchy) | 45.1670 µs | 68.499 ns | 33.297 ns | -51.161% |
+| yoga/100 nodes (2-level hierarchy) | 134.1250 µs | 378.22 ns | 336.53 ns | -10.862% |
+| yoga/1_000 nodes (3-level hierarchy) | 1.2221 ms | 3.2015 µs | 3.8928 µs | +21.080% |
+| yoga/10_000 nodes (4-level hierarchy) | 13.8672 ms | 37.347 µs | 36.162 µs | -11.971% |
+| yoga/100_000 nodes (5-level hierarchy) | 141.5307 ms | 1.5660 s | 1.6404 ms | -99.890% |
+| yoga /1_000_000 nodes (6-level hierarchy) | -  | - | 50.760 ms | - |
+| wide/10 nodes (2-level hierarchy) | - | 73.037 ns | 41.936 ns | -41.936% |
+| wide/100 nodes (2-level hierarchy) | - | 371.70 ns | 309.37 ns | -16.605% |
+| wide/1_000 nodes (2-level hierarchy) | - | 3.5458 µs | 4.3571 µs | +23.333% |
+| wide/10_000 nodes (2-level hierarchy) | - | 36.418 µs | 42.967 µs | +17.357% |
+| wide/100_000 nodes (2-level hierarchy) | - | 1.8275 ms | 3.9096 ms | +112.26% |
+| semi-wide/100_000 nodes (7-level hierarchy) | - | 2.6569 s | 1.4992 ms | -99.933% |
+| deep/4000 nodes (12-level hierarchy)) | - | 5.1845 s | 15.318 µs | -100.000% |
+| deep/10_000 nodes (14-level hierarchy) | - | 75.978 s | 40.315 µs | -100.000% |
+| deep/100_000 nodes (17-level hierarchy) | - | - | 2.7644 ms| - |
+| deep/1_000_000 nodes (20-level hierarchy) | - | - | 1.2130 s| - |
+| deep hierarchy/build  | - | 1.4869 µs | 713.45 ns | -4.4346% |
+| deep hierarchy/single | - | 7.1058 µs | 4.6564 µs | -2.0999% |
+| deep hierarchy/relayout | - | 3.7909 µs | 2.1306 µs | -2.4861% |
+| generated benchmarks  | - | 256.80 µs | 218.71 µs | -14.485% |