ParallelConversions benchmarks

Test done with a i7 10700K (8 Cores, 16 Threads). The Max Parallel Conversions only affects the conversion part, so if you just convert from CBR => CBZ, there will not really be a speed up. There needs to be a change like the file type.

The default value of ParallelConversions in the ComicRack.ini is 32. It is now capped at the Number of Cores available (previously it was 8). So if you leave the setting intact, you will have the number of conversion be the number of cores (with a max of 32). If you have more than 32 cores available, then you will need to edit the ComicRack.ini to change that value to what you want to use.

If you have less than 8 cores available than the value will be lower than what it was previously with the Original ComicRack, some testing would be need to show the real impact on those system.

Converting to WEBP

16 ParallelConversions (100% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	2.19GB	444MB	82019 = 80065 + 1954
#2	1129	1.70GB	514MB	79955 = 77965 + 1990
#3	1080	1.24GB	411MB	71747 = 70114 + 1632

8 ParallelConversions (75% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	2.19GB	444MB	92166 = 90438 + 1727
#2	1129	1.70GB	514MB	103405 = 101388 + 2016
#3	1080	1.24GB	411MB	90267 = 88664 + 1603

---

Converting to CBZ

16 ParallelConversions (35% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	2.19GB	2.19GB	18352 = 7498 + 10854
#2	1129	1.70GB	1.70GB	12684 = 6635 + 6048
#3	1080	1.24GB	1.24GB	10860 = 4547 + 6313

8 ParallelConversions (35% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	2.19GB	2.19GB	21252 = 7661 + 13591
#2	1129	1.70GB	1.70GB	14173 = 5838 + 8334
#3	1080	1.24GB	1.24GB	10330 = 4482 + 5848

---

Note

There was a bug that when converting an already WEBP file and keeping the format, it would output a jpeg file (with a WEBP extension). This has since been fixed, so this part of the benchmark might not be exact.

I wanted to test with the same file size output, than the first conversion to WEBP, to confirm that the Saving part was lower because of lower file size. So I just reconverted the resulting files. The size is double, because the resulting type was a JPEG instead.

Converting resulting WEBP to CBZ (Size is double)

16 ParallelConversions (15% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	444MB	803MB	101151 = 98111 + 3039
#2	1129	514MB	907MB	113645 = 110213 + 3432
#3	1080	411MB	751MB	99794 = 96929 + 2864

8 ParallelConversions (15% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	444MB	803MB	102093 = 99138 + 2955
#2	1129	514MB	907MB	113607 = 110252 + 3355
#3	1080	411MB	751MB	99422 = 96719 + 2702

---

Note

Because of the above mentioned bug, this would result in a JPEG to JPEG conversion instead.

Redoing a conversion from the bigger file, will be very quick and the file size remains the same.

Converting resulting Bigger WEBP to CBZ (Same file size)

16 ParallelConversions (50-60% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	803MB	803MB	6360 = 3287 + 3072
#2	1129	907MB	907MB	7463 = 3553 + 4110
#3	1080	751MB	751MB	6866 = 3033 + 3832

8 ParallelConversions (50-60% CPU Usage)

BOOK	# Pages	Starting Size	Resulting Size	Full = Convert + Saving (ms)
#1	1118	803MB	803MB	5963 = 3172 + 2791
#2	1129	907MB	907MB	7370 = 3481 + 3888
#3	1080	751MB	751MB	6118 = 3068 + 3049

Conclusion

So while doing a big conversion like JPG => WEBP, having the Max Parallel Conversions to the number of your CPU core (if more than 8 core available) will pretty much cap the conversion to 100% and there is a speed up from the old default of 8 Parallel Conversions, about 25 to 35%. Other than that there is no impact of that setting.