On Thu, 18 Oct 2018 08:58:04 -0400, Josef 'Jeff' Sipek wrote:
> On Thu, Oct 18, 2018 at 12:22:16 +0200, Gregory Szorc wrote:
> ...
> > Something else we may want to consider is a single Python module exposing
> > the Rust code instead of N. Rust’s more aggressive cross function
> > compilation optimization could result in better performance if everything
> > is linked/exposed in a single shared library/module/extension. Maybe this
> > is what you are proposing? It is unclear if Rust code is linked into the
> > Python extension or loaded from a shared shared library.
>
> (Warning: I suck at python, aren't an expert on rust, but have more
> knowledge about ELF linking/loading/etc. than is healthy.)
>
> Isn't there also a distinction between code layout (separate crates) and the
> actual binary that cargo/rustc builds? IOW, the code could (and probably
> should) be nicely separated but rustc can combine all the crates' code into
> one big binary for loading into python. Since it would see all the code, it
> can do its fancy optimizations without impacting code readability.
IIUC, it is. Perhaps, the rustext is a single binary exporting multiple
submodules?
I expect "rustext" (or its upper layer) to be a shim over Rust-based modules
and cexts. So if you do policy.importmod('parsers'), it will return
cext.parsers, whereas policy.importmod('ancestor') will return rustext.ancestor,
though I have no idea if there will be cext/pure.ancestor.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
