There is an obvious performance and memory issue with those bindings on larger
repos as it copies and allocates everything at once, round-trip. Like in the
previous patch series, this is only temporary and will only get better once
we don't have large data structures going to and from Python.
Details
- Reviewers
kevincox - Group Reviewers
hg-reviewers - Commits
- rHGce94f9622acd: rust-dirstate: add "dirs" rust-cpython binding
Diff Detail
- Repository
- rHG Mercurial
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Event Timeline
rust/hg-cpython/src/dirstate.rs | ||
---|---|---|
218 | let dirs_map = if ... Then just let the if statement evaluate to this value. |
rust/hg-cpython/src/dirstate.rs | ||
---|---|---|
218 | Ah yes, I always forget... Done in a future patch. |
+ def contains(&self, item: PyObject) -> PyResult<bool> {
+ Ok(self
+ .dirs_map(py)
+ .borrow()
+ .get(&item.extract::<PyBytes>(py)?.data(py).to_owned())
+ .is_some())
.contains_key(..) and .as_ref() instead of &...to_owned().
I'm surprised by the use of Deref in the previous patch. Is it legit
to leverage Deref to expose the inner type?
Ah yes, I don't know what I was thinking. I'll write a follow up.
To my eyes, the point of Deref is to make the struct act as a "fat pointer" from the outer interface code, but maybe this does not really help that much?
To my eyes, the point of `Deref` is to make the `struct` act as a "fat pointer" from the outer interface code, but maybe this does not really help that much?
I feel DirsMultiset isn't a HashMap, but is implemented by using a HashMap.
For example, inner.get().unwrap() returns a refcount of the path, but which
is an implementation detail.
So I think it's better to define methods explicitly instead of proxying
everything to HashMap.
Then just let the if statement evaluate to this value.