Nice! I wonder if it is possible to address this by making Node::ancestors return &Node, using a streaming iterator, without losing too much convenience...

Nice! I wonder if it is possible to address this by making Node::ancestors return &Node, using a streaming iterator, without losing too much convenience...

I don't think that is an API that we can generalize safely without still ensuring the node is rooted somewhere.

From what I understand (please correct me if I'm wrong), MutNullableDom still needs to do Dom::from_ref() internally (which accesses TLS on non-production builds). I experimented briefly with making a lifetime-bound iterator that worked only with Dom<Node>, but wasn't able to get it working. Maybe there is a way though.

Idly, I also wonder if we are simply optimizing non-production builds here as the TLS is accessed via debug_assert!.

Idly, I also wonder if we are simply optimizing non-production builds here as the TLS is accessed via debug_assert!.

I take profiles from a profiling build. If they are not representative of production ones we need to update their configuration.

Here we also avoid the whole rooting/unrooting which is not free anyway. I agree that we lose in ergonomics and that's annoying. There are many other places in node.rs that could benefit from a similar treatment (many if some_iterator().any(...) occurences) but that would become quite unreadable.

Nice! I wonder if it is possible to address this by making Node::ancestors return &Node, using a streaming iterator, without losing too much convenience...

I don't think that is an API that we can generalize safely without still ensuring the node is rooted somewhere.

It is if the reference refers to the iterator, which holds the root. But that requires fn next<'a>(&'a mut self) -> Option<&'a Node>, which is not compatible with the Iterator trait.

Idly, I also wonder if we are simply optimizing non-production builds here as the TLS is accessed via debug_assert!.

I take profiles from a profiling build. If they are not representative of production ones we need to update their configuration.

debug_assertions are disabled in profiling builds. The only difference is presence of debug information (should not affect perf) and that lto is thin instead of fat, which should only have a minor impact (and reduced link-time significantly).