EFForg/rayhunter

Multiple ideas for reducing binary size

Open

#441 opened on Jul 2, 2025

View on GitHub
 (3 comments) (0 reactions) (0 assignees)Rust (431 forks)github user discovery
Research Questionsenhancementhelp wanted

Repository metrics

Stars
 (5,271 stars)
PR merge metrics
 (PR metrics pending)

Description

A few people have tried to remove unused crate features etc in the project. Let's have a thread that collects all of what we've tried and what we still want to try. Help is wanted on this one, but we still have to discuss the improvements individually and whether they are worth it.

  • there is a single release zip. a user has to download all installers for all platforms just to run one. -- fixed with https://github.com/EFForg/rayhunter/pull/442
  • the installer pulls in too many features and dependencies -- fixed with https://github.com/EFForg/rayhunter/pull/436
    • adb_client is allegedly the biggest dependency, but i don't know enough about it
      • @oopsbagel says they're going to make an upstream PR to be able to disable unused code ("Image formats") in adb_client.
    • we use axum in exactly one place (tplink installer), maybe we can get away with something lighter.
      • if we do this we should consider doing the same in the daemon, to keep the tech stack similar
    • reqwest is going to be very heavy (#429), but i don't see a way out of this one
    • could we remove tokio entirely from the installer? how about the daemon?
      • if we stick with tokio, we should try to get rid of all spawn_blocking in the daemon. we currently use it in display code, and it's not necessary. if we can get rid of all, we could switch to single-threaded runtime and save a tokio feature.
  • web frontend is bloated -- fixed with https://github.com/EFForg/rayhunter/pull/435
    • sveltekit is unable to compress into one artifact, maybe move away from it to plain svelte + (random build tool)? (https://github.com/EFForg/rayhunter/pull/344#issue-3089511703)
    • we should make one JS file, one CSS file, and compress them before including them into the daemon binary. if we send the compressed artifact to the browser as-is, we do not have to bundle a gzip library.
      • memory_serve crate does something like this but also forcibly includes a brotli decompressor into the binary, which offsets all benefits (I've tried)
      • i think we'd have to make our own buildscript/proc-macro to realize this
  • orca.gif is bloated

PRs done so far

Contributor guide