You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 #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.
The text was updated successfully, but these errors were encountered:
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 #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.The text was updated successfully, but these errors were encountered: