diff options
| -rw-r--r-- | TODO.txt | 2 | ||||
| -rw-r--r-- | src/alf.1 | 22 | ||||
| -rw-r--r-- | src/alf.rst | 20 |
3 files changed, 26 insertions, 18 deletions
@@ -1,6 +1,6 @@ - fuzz unalf and unalf with afl++ or similar. -- clean up alf, try to make it faster. +- clean up crunch.c. - figure out why unalf craps out when extracting files of 15MB but works fine for 14MB. when this happens, there's no error, @@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. -.TH "ALF" 1 "2025-11-29" "0.2.1" "Urchlay's Atari 8-bit Tools" +.TH "ALF" 1 "2025-12-01" "0.2.1" "Urchlay's Atari 8-bit Tools" .SH NAME alf \- create Atari 8-bit ALF archives .\" RST source for alf(1) man page. Convert with: @@ -195,14 +195,18 @@ compress/decompress such files, and you\(aqd have to have a hard disk and a DOS capable of handling multi\-megabyte files... .SS Performance .sp -Performance is \fIhorrible\fP\&. This shouldn\(aqt be a real problem on -modern multi\-GHz CPU, especially since most Atari 8\-bit files are -small (usually under 64KB). Interestingly, it\(aqs not O(n^2), it scales -linearly, O(1): Compressing a 1.3MB text file takes 0.7 seconds on the -author\(aqs (rather modest) Intel i7 workstation, and a file 10x as large -takes approximately 10x as long (7 seconds). A 50KB file is almost -instantaneous, 0.05 seconds, which is more typical of the files you\(aqd -actually use this with. +Performance is pretty good, as of alftools\-0.3.0. For small files +like you\(aqd use on an Atari (up to 50KB), it\(aqs basically instantaneous +(under 0.02 seconds) on the author\(aqs modest i7 workstation. For a 1MB +text file, it takes 0.05 sec; for 1MB of random garbage, it\(aqs 0.1 +sec (and the resulting ALF file is 36% larger than the garbage). +.sp +By comparison, \fBzip\fP takes 0.6 seconds to compress the 1MB text file, +and 0.03 sec for the 1MB randomness (and the compressed file is still +larger than the input, but only by 312 bytes). The speed demon is \fBarc\fP: +it compresses the text file in 0.03s, and it\(aqs smart enough to \fInot\fP +compress the random garbage (it uses the \(aqstore\(aq method, which \fBalf\fP +doesn\(aqt have). .SS Timestamps .sp The date/time stamps stored in the archive are the \fBmtime\fPs of the diff --git a/src/alf.rst b/src/alf.rst index 4d48afc..0d2020e 100644 --- a/src/alf.rst +++ b/src/alf.rst @@ -170,14 +170,18 @@ a DOS capable of handling multi-megabyte files... Performance ----------- -Performance is *horrible*. This shouldn't be a real problem on -modern multi-GHz CPU, especially since most Atari 8-bit files are -small (usually under 64KB). Interestingly, it's not O(n^2), it scales -linearly, O(1): Compressing a 1.3MB text file takes 0.7 seconds on the -author's (rather modest) Intel i7 workstation, and a file 10x as large -takes approximately 10x as long (7 seconds). A 50KB file is almost -instantaneous, 0.05 seconds, which is more typical of the files you'd -actually use this with. +Performance is pretty good, as of alftools-0.3.0. For small files +like you'd use on an Atari (up to 50KB), it's basically instantaneous +(under 0.02 seconds) on the author's modest i7 workstation. For a 1MB +text file, it takes 0.05 sec; for 1MB of random garbage, it's 0.1 +sec (and the resulting ALF file is 36% larger than the garbage). + +By comparison, **zip** takes 0.6 seconds to compress the 1MB text file, +and 0.03 sec for the 1MB randomness (and the compressed file is still +larger than the input, but only by 312 bytes). The speed demon is **arc**\: +it compresses the text file in 0.03s, and it's smart enough to *not* +compress the random garbage (it uses the 'store' method, which **alf** +doesn't have). Timestamps ---------- |