Currently, the check we run to determine whether the current Node process is running under musl libc—and thus which Linux binary to use for the embedded compiler—is very expensive. This is particularly problematic in light of https://github.com/sass/embedded-host-node/pull/313, which runs this check for every CLI invocation of the Sass compiler.
We should find a way to drive this cost down in order to minimize the overhead of starting the embedded host or the CLI. One option would be to port the Ruby host's ELF-parsing logic, although that's fairly complex. There are a few ELF parser libraries on npm, but none of them seem to support synchronous mode and operating on a file descriptor rather than the whole executable, both of which are hard requirements here. It's possible there are other solutions, like looking for /lib/libc.musl-x86_64.so.*, but we'd have to do some research to verify that that's reliable.
I can take the action and write a simplified ELF parser as the goal is to only extract the interpreter and we don't need a lot other fields that ruby implementation extracts.
Currently, the check we run to determine whether the current Node process is running under musl libc—and thus which Linux binary to use for the embedded compiler—is very expensive. This is particularly problematic in light of https://github.com/sass/embedded-host-node/pull/313, which runs this check for every CLI invocation of the Sass compiler.
We should find a way to drive this cost down in order to minimize the overhead of starting the embedded host or the CLI. One option would be to port the Ruby host's ELF-parsing logic, although that's fairly complex. There are a few ELF parser libraries on npm, but none of them seem to support synchronous mode and operating on a file descriptor rather than the whole executable, both of which are hard requirements here. It's possible there are other solutions, like looking for
/lib/libc.musl-x86_64.so.*
, but we'd have to do some research to verify that that's reliable.