Summary:
EdenFS will now be able to fetch blobs directly from memcache. This won't have
any big benefits as no blobs are in memcache right now, but over time, this
will significantly reduce the cost of fetching blobs.
Reviewed By: fanzeyi
Differential Revision: D19861643
fbshipit-source-id: c2e9d317bd30d4656bf0b3f8897794161697761a
Summary:
These tracing points will help us understand the memcache hit rate as well as
the fetching speed.
Reviewed By: quark-zju
Differential Revision: D19836499
fbshipit-source-id: 1936c44efc3e7715069e6a959f5331139d591d5c
Summary:
Everytime a cache miss is seen, the data fetched from the server will be sent
directly to memcache for future use. Unfortunately, doing so in a blocking
manner severely impact the overall fetching speed from the server. Since
memcache is purely an optimization, we can afford to send data to it
asynchronously.
Let's move as much as possible of the code to a background thread to reduce the
overhead of memcache.
Reviewed By: DurhamG
Differential Revision: D19836011
fbshipit-source-id: 68e506ef7464d6e99d98457d0d37178f514be1a9
Summary:
Instead of fetching data one-by-one, let's prefetch data concurrently by using
the new get_iter function.
Reviewed By: DurhamG
Differential Revision: D19836009
fbshipit-source-id: 4a50328c0cbbba677c2de3777ebe4c34cb10c1e2
Summary:
Even when memcache would be able to prefetch everything, this would always call
into the underlying remote store with an empt key set. For things like `hg
prefetch` and a large number of keys, the effect of doing that is minimum, but
for EdenFS or `hg log -p`, the roundtrip to the server for every file/revision
would add a significant amount of overhead. Let's simply stop iterating when we
no longer need to fetch anything.
Reviewed By: DurhamG
Differential Revision: D19835797
fbshipit-source-id: 54ad704428c3b20d973cfa87f7171899ec44b3f9
Summary:
See also https://github.com/serde-rs/bytes/.
This will be used in the `dag` crate.
Reviewed By: DurhamG
Differential Revision: D19770858
fbshipit-source-id: 2a870a564e0ceecdc7a4667853b2b2a5ea4ce6e3
Summary:
This crate provides the core features of the commonly known `Bytes` crate:
zero-copy slicing and cloning, while also supports mmap-backed buffers.
The main motivation is to replace `Mmap` in `indexedlog`. That has multiple
benefits:
- Handles 0-sized mmap more cleanly.
- Handles clones more cleanly.
- Gain the flexibility to zero-copy data without lifetime / reference.
- Gain the flexibility to switch to non-mmap data.
The `bytes::Bytes` crate does not yet support mmap buffers as of its latest
release (0.5.4).
Implementation wise, `minibytes::Bytes` uses `Option<Arc<dyn Trait>>` for the
"trait object". This makes implementing the mmap storage just one line.
`bytes 0.5.4` re-invents the "trait object" manually using unsafe code. It requires
about 50 lines to implement the mmap storage (in D19756122).
Reviewed By: xavierd
Differential Revision: D19770856
fbshipit-source-id: 8cfa7052a18ac2e0cd6348b77d5e2a4acc61195c
Summary: This makes the output more readable even if the "name" of a span is very long.
Reviewed By: DurhamG
Differential Revision: D19780536
fbshipit-source-id: dce0d3777409c32b0752db51341a572addb823ea
Summary:
As initializing the memcache client takes ~0.7s, let's move it to a background
thread as to not impact Mercurial startup time. This diff uses ArcSwap in
order to reduce the overhead of the very common read paths as much as possible.
Using Mutex or RwLock instead would have caused unecessary contention.
Reviewed By: DurhamG
Differential Revision: D19518693
fbshipit-source-id: 886e9b86813fda6ff005ccce99659890026f643a
Summary:
This allows the Python code to build a memcache client and build ContentStore
and MetadataStore with it.
Reviewed By: DurhamG
Differential Revision: D19518694
fbshipit-source-id: d932fd5223ccfdf37db69cbb54a11a6571312709
Summary:
This enables an in-process memcache client for the Rust
ContentStore/MetadataStore. For now, this implementation is lacking several
necessary optimization:
- Start-up time is always slowed down by ~0.7s, the initialization will be
moved to a background thread
- Writing data to memcache is blocking and will be moved to a background
thread too.
- Prefetching data does a roundtrip to memcache for every key, batching
memcache APIs will be added.
Compared to the existing hg_memcache_client, this implementation is both
significantly shorter and do not exhibit some of the pathological behavior of
having to flush the indexedlog for every fetched blob when used in Eden.
Reviewed By: DurhamG
Differential Revision: D19518696
fbshipit-source-id: 4725447d13e7eddd9586135c2511e13ddb921771
Summary:
The library already has a way to wrap a Python object into a Rust object that
exposes the Rust Read/Write interface. This is the reverse direction for
the Write interface.
The initial intention is to expose Rust stdout as described in D19702533.
However, I found Python's `sys.stdout.buffer` also enforces utf-8 encoding
on Windows (unless PYTHONLEGACYWINDOWSSTDIO is set). So Python's
stdout actually behaves similarly with Rust's stdout on Windows and is okay
to use. That said, it's still useful to have this abstraction, for streampager [1]
integration.
[1]: https://github.com/markbt/streampager/
Reviewed By: sfilipco
Differential Revision: D19716127
fbshipit-source-id: ba39898122561d9a49b7080ee95d7c940540eb40
Summary:
Drop stdoutbytes/stdinbytes. They make things unnecessarily complicated
(especially for chg / Rust dispatch entry point).
The new idea is IO are using bytes. Text are written in utf-8 (Python 3) or
local encoding (Python 2). To make stdout behave reasonably on systems not
using utf-8 locale (ex. Windows), we might add a Rust binding to Rust's stdout,
which does the right thing:
- When writing to stdout console, expect text to be utf-8 encoded and do proper decoding.
- Wehn writing to stdout file, write the raw bytes without translation.
Note Python's `sys.stdout.buffer` does not do translation when writing to stdout console
like Rust's stdout.
For now, my main motivation of this change is to fix chg on Python 3.
Reviewed By: xavierd
Differential Revision: D19702533
fbshipit-source-id: 74704c83e1b200ff66fb3a2d23d97ff21c7239c8
Summary:
All diff functions are (bytes, bytes) -> bytes to preserver
the original file encoding.
Because of that I had to add ui.writebytes output function that accepts
bytes for terminal output.
Reviewed By: farnz
Differential Revision: D19656673
fbshipit-source-id: b9a1e4361e825fc8c2313e8402c2bbe00f490dd4
Summary: `PyPath` is to `PyPathBuf` as `Path` is to `PathBuf` and `str` is to `String`.
Reviewed By: quark-zju
Differential Revision: D19647995
fbshipit-source-id: 841a5f6fea295bc72b00da028ae256ca38578504
Summary: Username as utf8, so let's make mutationmarker treat them as such.
Reviewed By: xavierd
Differential Revision: D19649887
fbshipit-source-id: 3f8b2db434a57ee8ee3017de8d925c19a2002b20
Summary: Add `PyNone`. This is a marker struct that indicates that a python function can only return `PyNone`.
Reviewed By: xavierd
Differential Revision: D19644338
fbshipit-source-id: f846b146237ebf7de996177494934fec662cde0f
Summary:
`PyPath` is the type that owns the data. Rename it to `PyPathBuf` for analogy
with `PathBuf` and `RepoPathBuf`, and to allow us to introduce a reference type
named `PyPath`.
Reviewed By: xavierd
Differential Revision: D19643797
fbshipit-source-id: 56d80fea5677f7223e967b0723039d1763b26f68
Summary:
Make the type easier to use. Namely, the treestate bindings want PyPath <->
bytes since treestate internally uses bytes.
Reviewed By: xavierd
Differential Revision: D19635357
fbshipit-source-id: 37d1889b5da1d7f3869bb7820de0219b87b71a8b
Summary:
Set up the `cpython-ext` and `hgcommands` libraries so that they can compile
against py2 and py3 versions of rust-cpython. Make py2 the default so
that cargo test still works.
Reviewed By: singhsrb
Differential Revision: D19615656
fbshipit-source-id: 3403e7077deb3c0a9dfe0e3b7d4f4ad1da73bba3
Summary:
Update the Rust hgcommands code to pass the command line arguments into the
Python logic as `Str` types, so that this will be Unicode `str` objects when
using Python 3.
Reviewed By: xavierd
Differential Revision: D19596739
fbshipit-source-id: 7cdfd44a1c4ce8b0f86d20b634d9b27eab822b2d
Summary: This is incorrectly removed due to a bad rebase / merge.
Reviewed By: DurhamG
Differential Revision: D19607801
fbshipit-source-id: a6ee7a3f184ff1882eb1f1513f7fed74a7108727
Summary:
This makes `make hg3` work. It requires cleaning up the `build` directory when
switching between py2 and py3 build, which will be fixed later.
Reviewed By: DurhamG
Differential Revision: D19604824
fbshipit-source-id: 060ff313420126a5dba935c4451b45dc9af45f13
Summary: Add methods to convert to a `Str` object from `String` and from `Vec[u8]`
Reviewed By: xavierd
Differential Revision: D19596743
fbshipit-source-id: 6499f7f1b8329f4d14ce8179a41ed46982a85c8e
Summary: Update to the new version of rust-cpython. This supports `list.append`, so make use of it.
Reviewed By: xavierd
Differential Revision: D19590905
fbshipit-source-id: 03609d4f698ae8e4380e82b8144caaa205b4c2d4
Summary:
Also, add a util::path::strip_unc function that is more clear than the
normalize_for_display
Reviewed By: DurhamG
Differential Revision: D19595961
fbshipit-source-id: 330bcb708bf64320a3562d79db685d6cb1e14f16
Summary:
For Python3 compatibility, let's use PyPath, it hides the logic of encoding for
Python2
Reviewed By: DurhamG
Differential Revision: D19590024
fbshipit-source-id: 7bed134a500b266837f3cab9b10604e1f34cc4a0
Summary:
This is optional, but it helps investigating Python errors chained with other
Rust errors.
For example:
error.RustError: failed fetching from store (, cc38739855a7f356b4a2aaac0a0a858fd646e6bf)
Caused by:
TypeError()
Traceback (most recent call last):
File "scm3/edenscm/hgext/remotefilelog/contentstore.py", line 53, in get
chain = self.getdeltachain(name, node)
File "scm3/edenscm/hgext/remotefilelog/contentstore.py", line 91, in getdeltachain
chain = self._getpartialchain(name, node)
File "scm3/edenscm/hgext/remotefilelog/contentstore.py", line 125, in _getpartialchain
return store.getdeltachain(name, node)
TypeError
Without this diff there is only "TypeError()" without the traceback.
This can be turned off by unsetting RUST_BACKTRACE.
Reviewed By: markbt
Differential Revision: D19581173
fbshipit-source-id: 74605b78146b6b1c9ddd5ad720dcd19ff73908a8
Summary: The format_err is used in shared code too, we need to import it.
Reviewed By: quark-zju
Differential Revision: D19592591
fbshipit-source-id: bd344bf3c295473f4647235a98432d11c9678bf9
Summary:
This will be used as an argument to the Rust bindings when using paths. This
type is either a PyBytes in Python2 and uses the various encoding function to
convert into a String, or a PyUnicode in Python3 with no encoding change.
Reviewed By: farnz
Differential Revision: D19587890
fbshipit-source-id: 58903426585693193754691fe3c756b9097b35f6
Summary:
Without this, Rust code using the feature (ex. lz4, used by lz4revlog) will
panic.
Reviewed By: sfilipco
Differential Revision: D19581188
fbshipit-source-id: b499449df4fede27fe66cf8e5af57e8347a0dd48
Summary: This converts to bytes on Python 2, but unicode on Python 3.
Reviewed By: markbt
Differential Revision: D19581180
fbshipit-source-id: 0de9056a01ae30810a72352387de5a940b37d7ab
Summary:
In a future diff, I have RepoPath in Rust and want to send unicode path to
Python.
Reviewed By: sfilipco
Differential Revision: D19581184
fbshipit-source-id: 73a03707a6bdae4a497a8ee2c14314aa4ffefb6d
Summary: The docs promise that both `<` and `>` bounds are inclusive, so let's fix that.
Reviewed By: markbt
Differential Revision: D19580840
fbshipit-source-id: 13770a8e9351fe62f58e9a701b526a167752543a
Summary:
Separate Segment and IdDag in two individual files. This is preparation for
refactoring IdDag to be more flexible in terms of storage. That will probably
involve moving stuff out of IdDag into a new file that deals with the storage
abstractions.
Reviewed By: quark-zju
Differential Revision: D19559127
fbshipit-source-id: b3b9b18e2653157e69148b1f29292a57b30016ec
Summary:
I wrote it to understand how renderdag draws the same graph with different
orders. It seems useful for future optimization that tries to reduce the number
of columns. So let's check it in.
Reviewed By: xavierd
Differential Revision: D19440713
fbshipit-source-id: 8bc580799f6b24c87886d5ac306020f50bb694e5
Summary: This gives us some confidence about octopus merge handling.
Reviewed By: DurhamG
Differential Revision: D19540726
fbshipit-source-id: e84de74aecae54429483edd185d39fd1bd858f87
Summary:
TestContext uses ParentRevs. That limits parents to at most 2.
Use a type parameter so we can opt-in Vec<usize> for octopus merge support,
at the cost of worse cache efficiency.
Reviewed By: DurhamG
Differential Revision: D19540727
fbshipit-source-id: f9e8de151b7b296fd6f0fd89be9de2b8996634c7
Summary:
Our new algorithms support octopus merges. However there were no tests using
octopus merges. This diff adds a simple one.
Reviewed By: DurhamG
Differential Revision: D19540728
fbshipit-source-id: 8411024f0b7e27c2ebfabbe1935496124c25df7b
Summary:
The test runs the old and new algorithm and compares their result. This is more
interesting than using random numbers, since the fuzzing framework will try to
explore new code paths.
Reviewed By: sfilipco
Differential Revision: D19511576
fbshipit-source-id: e9a2066769b54a60bb92643e5715f91a6fccbcb5
Summary:
The ported algorithm will work as a comparison to verify dag's range
implementation.
Reviewed By: sfilipco
Differential Revision: D19511574
fbshipit-source-id: 589353d6e6c91b8d6707c977eeb8558ac733b525
Summary: This can prevent potential moves and clones on the caller of prefetch.
Reviewed By: quark-zju
Differential Revision: D19518697
fbshipit-source-id: 63839fc3f4bb9ca420e290eabaffb481a3584f7b
