Use zeroperl?

[mceachen]

Manually converted from #229:

Hey folks,

Love the work you've undertaken with this library. I just wanted to put on your radar a library we just released that leverages our other project, zeroperl, to execute ExifTool without needing to ship or rely on Perl distributions.

[mceachen]

@andrewmd5 interesting work!

A couple of questions for you:

0. What file types have you tested against? ExifTool handles literally thousands of variants, and those variants may rely on different parts of the perl runtime that zeroperl may not be gracefully spoofing yet.
1. You'll really want to automate upgrading to new versions of ExifTool. Phil releases frequently.
2. Have you done any performance testing on macOS, Windows, and Linux?
3. If you're entering the perl interpreter afresh for every metadata read, you're going to see 10-100x slowdown compared to using stay_open. Check this library for tips on how it works (and the shenanigans you have to go through in order to encode and decode stuff you get back from exiftool).
4. How big does the Node.js VM get when all of perl and exiftool are loaded?

As far as collaborating, it might make sense for this library to add a new option to use zeroperl instead of forking exiftool? I'd appreciate pointers on how I'd go about that.

[andrewmd5]

What file types have you tested against? ExifTool handles literally thousands of variants, and those variants may rely on different parts of the perl runtime that zeroperl may not be gracefully spoofing yet.

Basically all file types are supported; the only thing not supported is native process launching - ExifTool tries launching mdls on macOS to extract further data. My current idea is to implement that at the WASI layer so you can launch it and return the output back to Perl.

You'll really want to automate upgrading to new versions of ExifTool. Phil releases frequently.

We're pinned to production releases of ExifTool (currently that is 13.10, but we're on 13.11 because it's what development started with). I can set up a workflow that automatically builds the latest release if it's helpful.

Have you done any performance testing on macOS, Windows, and Linux?

It's 30% of native speed in mature WebAssembly runtimes (browser, node). So roughly 300 ms to extract full metadata from a 30GB Apple ProRes footage.

If you're entering the perl interpreter afresh for every metadata read, you're going to see 10-100x slowdown compared to using stay_open. Check this library for tips on how it works (and the shenanigans you have to go through in order to encode and decode stuff you get back from exiftool).

Actually, thanks to the magic of V8 WASM caching, we don't see this slowdown (I expected it too). That being said, I don't think stay_open is possible unless we make reading from standard input asynchronous too, but this might be more trouble than it's worth.

How big does the Node.js VM get when all of perl and exiftool are loaded?

~75-100 MB of memory usage, which I think can be lowered if we reduce the 8 MB stack it allocates.

If you can take a look at the API for our ExifTool library and let me know of any changes that would make it easier for you to integrate, then I'll make those and we can riff a bit on design.