blob: 230e6e3630875a87c2c0a77fce0dc66d1acccb75 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
First run on a big folder (1.1Go)
==================================
The program was for the first time run against a fairly big folder: my Desktop
folder.
It is a composite folder that contains a lot of different things, among which:
- a lot of downloaded PDF files
- a lot of downloaded image files
- a massive (715,3Mio) package of binary updates
- a TV show episode (85Mio)
- some other fat binary executables (108Mio)
- some compressed packages (53Mio)
_I am started to understand the bad compression performances_
## Resources
- CPU: 90% 4 cores
- RAM: 0.7% 16Go
## Time
`16:00:04` → `16:12:33` = `00:12:29`
## Size
### Original
```
1050129 kio
```
### Repo
```
18 kio test_1/00000/files
1017586 kio test_1/00000/chunks
5908 kio test_1/00000/recipe
1023515 kio test_1/00000
1023519 kio test_1
```
saved:
```
26610 kio
```
## Notes
Not really impressed by the saving, even when there are a lot of deduplicated
files.
There are a lot of chunks larger than uncompressed ones
(8208o instead of8192o).
This is probably because of the added Zlib header and the fact that no
compression was achieved.
## Conclusions
1. I should probably test with a folder that contains less binary and compressed
data.
2. Maybe we can store the chunks uncompressed when we detect that it uses less
space than the compressed version.
Second run on source code folder (1.0Go)
=========================================
## Resources
Similar
## Time
`17:09:01` → `17:13:51` = `00:4:50`
## Size
### Original
```
925515 kio
```
### Repo
```
6433 kio test_2/00000/files
272052 kio test_2/00000/chunks
17468 kio test_2/00000/recipe
295956 kio test_2/00000
295960 kio test_2
```
saved:
```
629555 kio
```
|
