I believe that sharing a common loan with the "speed" of a modern JS translator is far offtopic in Bellar's list of methods (since it does not replace the browser mechanism). What are its optimization methods? is an excellent question, and I would like to receive a more detailed record of this.
Points that I can name so far
- (Optional) Massive JS arrays eliminate unnecessary memory allocation dynamics (resizing). A fixed type (size) allows you to select continuous memory blocks (without segments of variable length elements in such blocks) and evenly address elements of the same type.
- Fast boot using a custom minimalistic bootloader (see the linuxstart code published by Fabrizio, also see his project called TCCBOOT http://bellard.org/tcc/tccboot.html )
- Optimized uncompressed embedded kernel (see kernel configuration, it is very small and optimized for small "linux").
- Minimum number of devices (Devices are super-standard and easily recognized by the kernel. So far I have studied the serial device correctly, but the rest is the advantage of such properties). Ramdisk initialization is rather slow, though.
- Small (2048 blocks) uncompressed root.bin ext2 system. The root system consists of a minimal combination (rootfs, proc, tmpfs, devpts). No exchange.
- (Not sure) he fixed the buffer size for ttyS0 (serial port device or, indeed, the kernel UART driver - to be precise), which communicates with the terminal. The connection is buffered in some way using its term.js binding (I myself did not find the transfer buffer in the UART itself). Note that emulation (as in this case) can be much faster than the real thing.
Also pay attention to the browser cache when refreshing the page. It works very fast if everything is in memory (optimized by the host operating system). Performing direct (if cached in memory) copying (with load_binary ()) of the "uncompressed" binary segments (start_linux.bin, vmlinux26.bin, root.bin). There are no I / O limits on the hard drive.
Yauhen yakimovich
source share