resource_dasm
resource_dasm copied to clipboard
fuzziqersoftware
Suggestion: Conditional compilation for some features
My July 2022 build of resource_dasm was 13 MB, and the one I did just now is 12.5 MB (Intel)
I thought maybe separating the disassembly stuff would make the build smaller, but it didn't seem to help?
It's a low priority issue. But I plan to bundle resource_dasm, picttoppm, and a 3rd program I am developing (a converter) which will convert 90's (Al Staffieri) GameMaker games to a new modern runtime (a 4th program that's long been written). All the program sizes add up I guess, and my first computer was an LC II with 4 MB of RAM and an 80 MB hard drive and I never quite shed that mentality ;)
I remember ~2 years ago hacking a build of resource_dasm that was much smaller after cutting out everything except for the PICT and 'snd ' converters.
I could probably take a stab at it, basically would just be a bunch of #ifdef statements?
Also, here is my latest build for Intel, from Nov 12 2022 master. If anyone out there just needs binaries and can't figure out how to build it for some reason.
Built on Catalina and tested on whatever 12 is. Mexico or something.
The executable size bothers me too, I must admit... I remember when programs had to be efficient, and I do kind of miss those days.
I have the build type statically set to Debug in CMakeLists.txt for my development convenience, but switching it to Release cuts the executable size down by quite a bit - I get a 4MB binary after doing so (at the cost of not being able to debug it, which seems fine for your use case).
Beyond that, a quick look into libresource_file.a shows that the largest object code segments in the Debug build are (as expected) the emulators/disassemblers at a couple of MB each, and (surprisingly) some of the static data structures. Removing some static data structures is probably not hard; not many things depend on TrapInfo, and SystemTemplates can be avoided too if needed. Removing the x86 and PPC emulators is probably feasible as well, but removing the 68K emulator would disable some potentially critical functionality (the ability to handle compressed resources). Removing the disassemblers from the emulators is probably not feasible without a lot of work.
I'll see if I can cut down the build size a bit when I get some time in the next few days. I can't promise a quick resolution here, unfortunately, but you're welcome to take a stab at it too if you'd like.
I was thinking that the CPU specific stuff must be in the library. (And I'd figured the library was statically included in all the binaries, but that works just fine for my use case).
Here's everything built for Intel, with Release instead of Debug. Much smaller.
But we're back up to almost 9 MB when I paste together Intel and ARM.
Maybe a quick/easy win for build size would be a flag to exclude the PPC emulator and disassembler.
I rebuilt resource_dasm with -O2, and the size went from 12.3MB to 4.5MB. Intel x64, MacOS 10.14, Apple clang version 11.0.0. -O2 doesn't make debugging more difficult in my experience.
Edit: strip resource_dasm to remove non-public symbols shrinks it to 2.3MB (but obviously makes debugging impossible).
