Let's say I have an app with a bunch of binary assets (icons, images, audio, etc.). What would make my application run faster: using include_bytes! macro or using std::fs to load files?
include_bytes! will load the file with the executable itself (usually mapping the whole file to memory) so it's definitely faster. The downside of include_bytes! is you would have to recompile the application each time you update a resource.
If you're on Windows, you should probably use the loader's API for resources (LoadResource) as it would save you from recompiling the executable each time and will use the already mapped HMODULE.
Does loading executable into memory not take time? Audio files can be loaded as stream and played lazily, while include_bytes! would load them eagerly. I also wonder about bundled application like AppImage, how do they differ from include_bytes!.
Both are valid options… which is faster depends on the details.
I don't really know the specifics of AppImage. Generally speaking, the loader will take a bit more time (it really depends on resource sizes) to load embedded resources. But it's faster to load one "large" file than many small ones.
From what I read, AppImage contains a squashfs image that is mounted to a temporary location. Meaning the resources will not be loaded unless explicitly accessed (or included in the binary itself with include_bytes!).
At least on Linux, embedded data becomes part of the executable's mmap at runtime, but apart from consuming a fixed amount of virtual address space, there's not much cost to this. That content won't be loaded in physical memory until you actually access those addresses, same as any other part of the process. Then you'll get a page fault, where the kernel will load the content if it's not in already in the file cache, then set the page mapping in your process.
But in general -- when in doubt, measure it!
1 Like
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.