Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

On Mon, Jul 16, 2018 at 3:56 PM, Barry Warsaw <[email protected]> wrote:
> * How do you achieve faster hot start times with XAR over native file
> system?  That's a bit unexpected, although based on our shiv work, I can
> imagine some things about how you start Python or lay out the code that
> might provide better hot start times (e.g. fewer entries on sys.path and a
> fanatical avoidance of pkg_resources).  OTOH, I'd think that relying on FUSE
> would impose some additional overhead over native file systems.

Hi all,

I collected the XAR benchmark numbers. I spent some time today
investigating what
exactly is causing the difference between native and XAR start times. The native
installation I was benchmarking against used `pkg_resources.load_entry_point()`
to run the script, while XAR called the entry point directly.

I didn't realize that `pip install .` behavior differs based on
whether `wheel` is
installed or not. When wheel is installed pip uses `bdist_wheel` to
build the package
and uses its own loader script which calls the entry point directly.
When it isn't it
uses `python setup.py install` to build the package and uses the
setuptools loader
script which use `pkg_resources.load_entry_point()` to call the script.

If I rerun the experiment with the wheel loader script (without pkg_resources),
I see these hot start times:

black: 0.171 s (vs 0.208 for XAR)
jupyter-nbextension: 0.165 s (vs 0.179 s for XAR)

Without the pkg_resources difference we have a small overhead over
native installs.

Best,
Nick
--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/E7J7NP4VVHYPSALAFREO53QUO6FIM6PK/