-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running time benchmark of Tebako generated packed-mn #143
Comments
I believe that it is not possible to avoid overhead for simple command like './metanorma-linux-x64 help' I think for metanorma site generate the difference with native invokation wil be smaller |
@maxirmx Why do we need to extract executable files to temp? That's what we're trying to avoid by directly mounting the DwarFS volume? Ruby-packer does not need to extract anything to temp. |
@ronaldtse I do exactly the same. There is no way to load shared libraries, jars etc, from memfs unless this memfs is mounted as conventional file system. I believe we have discussed it here: tamatebako/tebako#45 (comment) |
From glibc, can't we redirect |
And overriding |
The issue not with redirecting dlopen, we redirect it already in order to use temp file we create. You are probably talking not about overriding dlopen but about patching its internals or developing our own dynamic loader. If you mean it, I can create our version of dynamic loader. I will ask for 3-4 months. |
I was thinking if we can have dlopen that redirects to files loaded via libdwarfs (from dwarfs image directly, not extracted as a temp file). i.e.:
|
Using a locally-compiled packed-mn using Tebako on Linux:
I downloaded the latest ruby-packer generated metanorma 1.5.4pre from here:
https://github.com/metanorma/packed-mn/releases/tag/v1.5.4pre
Results:
When running the metanorma bundle directly (in the same container):
TLDR:
bundle exec
). Tebako should have its own benchmarks to see how to optimise.The text was updated successfully, but these errors were encountered: