I was just having a look at the packfile format code, and I have a suggestion on load-time performance of the code segment.
Currently, you read the file, parse out the various sections, copy them elsewhere in memory, and byte-swap as necessary. The overhead of doing this could be quite significant on large applications/modules. A "trick" that I've found very useful in the past is to design the bytecode format so that it can be mmap'ed into a block of memory, and then executed almost immediately with the minimum number of fixups. Rather than copying the instructions, you execute them directly out of the mmap'ed region. This has several benefits. The obvious one is less copying during program loading. But less obvious is that it can make the OS kernel do the hard work for you. When a region is mmap'ed read-only, the OS kernel can manage memory better. When memory gets tight, it can simply discard the page, as it can always go back to the file to get it again. A malloc'ed page, by comparison, must be copied out to the swap file, which incurs additional overhead. Even better, the kernel will perform demand-paging of the bytecode into memory as the code is executed, giving much faster startup times. Multiple processes accessing the same module will share the same page. Copying everything into a malloc'ed region defeats demand-paging. Of course, this is only going to work if the packfile matches the host endianness exactly. A byteswap is still required if the endianness doesn't match. However, in any given install, it is 95% likely that the pre-compiled modules will be set up with the host order. Key to making this work is that fixup information must be well isolated within the file. e.g. references to external functions is by static index into a fixup table, not by applying a relocation directly to the main code segment. If you ever wonder why PIC-format ELF binaries are so weird, it is to harness the mmap system deep inside the kernel to do most of the hard work. Just an idea. Apologies if I'm rehashing something that has already been discussed previously and discarded. Cheers, Rhys.
