1 | Idea is very simple — in the runtime we don't need to process or understand archive format. Wwe just need to know file data ranges. Where file data begins and where ends.
|
2 |
|
3 | Builder is more complicated — builder should compute such data ranges.
|
4 |
|
5 | In the first prototype ZIP was used (because format is very simple). But there are 2 drawbacks:
|
6 |
|
7 | 1. Size. Test app 37.853 vs 34.218 3MB for simple app and much more noticiable difference for big application (confirmed by some user app). Because https://sourceforge.net/p/sevenzip/discussion/45798/thread/222c71f9/
|
8 | 2. No way to ask 7za to write file modification timestamps for ZIP format. And so, checksum for the whole file always mismatch.
|
9 |
|
10 | Yes, we can remove timestamps, but... after first working prototype it was clear that task is not so complex. As stated above, runtime implementation is simple.
|
11 | So, why not just port Java implementation of 7z format to TypeScript?
|
12 |
|
13 | ## Package File
|
14 |
|
15 | (size as in a windows explorer)
|
16 |
|
17 | 7z - 34.134 Compression time 26s
|
18 |
|
19 | zip(lzma) - 37.612 Compression time 26s (~ the same time (as expected, because filters, as documented, are very fast ())
|
20 |
|
21 | zip(xz) - 37.619 Not clear why. xz supports filters, but it seems 7z doesn't apply it correctly.
|
22 |
|
23 | Onshape test app:
|
24 |
|
25 | ```
|
26 | ZIP: 37.853
|
27 | 7za solid: ~32
|
28 | 7za not solid: 34.218
|
29 | 7za not solid and header compression disabled: 34.225
|
30 | ``` |
\ | No newline at end of file |