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, we fully load Mach-O binaries in memory for signing. This was convenient to implement because Rust Mach-O parsers like to use 0-copy and operate on full Mach-O data.
We could mmap the file. But copying the binary content will fault the full content and balloon memory to the size of the Mach-O. So we're back where we started in terms of resident memory usage.
Another consideration is effects on in-place signing. By buffering the entire file in memory, we don't have to worry about reads after writes like we would with updating a file in-place.
Filing this feature request to not buffer the Mach-O in memory. This is a lot of work and will require refactoring a lot of APIs. But it should result in significant performance improvements for large (1+ GB) binaries or machines with slow disks. (I'm less sympathetic to slow disks since generally people signing are using SSDs these days or any I/O slowness will get mitigated by the page cache.)
Related to #11. Please comment on that issue regarding performance concerns.
The text was updated successfully, but these errors were encountered:
Currently, we fully load Mach-O binaries in memory for signing. This was convenient to implement because Rust Mach-O parsers like to use 0-copy and operate on full Mach-O data.
We could mmap the file. But copying the binary content will fault the full content and balloon memory to the size of the Mach-O. So we're back where we started in terms of resident memory usage.
Another consideration is effects on in-place signing. By buffering the entire file in memory, we don't have to worry about reads after writes like we would with updating a file in-place.
Filing this feature request to not buffer the Mach-O in memory. This is a lot of work and will require refactoring a lot of APIs. But it should result in significant performance improvements for large (1+ GB) binaries or machines with slow disks. (I'm less sympathetic to slow disks since generally people signing are using SSDs these days or any I/O slowness will get mitigated by the page cache.)
Related to #11. Please comment on that issue regarding performance concerns.
The text was updated successfully, but these errors were encountered: