Should SumatraPDF be more lightweight?

[dungsaga]

I read the blog post Lessons learned from 15 years of SumatraPDF, an open source Windows app and appreciate the effort to make it the most lightweight PDF reader today.

But then I recall that it was much more smaller when it was announced. I found some old 32-bit versions in FileHorse:

The size of the installer increased from 1MB to 4MB to 6MB. The installed size would be around 2.2 or 2.5 times bigger.

I understand that SumatraPDF depends from libmupdf (which is 11MB in my 64-bit version) and libmupdf support many more file formats than Poppler. On top of that, SumatraPDF added support for many compressed archive formats and modern image formats.

I wonder if we can make it more lightweight like its previous versions by splitting some supports into DLL files that would be loaded dynamically. Would it be smaller if we use Poppler instead?

It's interesting to read the SumatraPDF version history, in version 0.9 : "removed poppler rendering engine resulting in smaller program and updated to latest mupdf sources". At that time, the installer was only 1 MB.
The growth of mupdf contributes a lot to the size of SumatraPDF. Mupdf even added support for MOBI recently.

This is not a complain about SumatraPDF. I still love it and understand that today it comes with lots of functions and it's still smaller than other PDF readers (The little Foxit Reader is already bloated over 150 MB).

This is just a what-if kind of thought experiment I have when I look at the smallest PDF freemium editor : PicoPDF

[kjk]

Majority of the size are fonts. Without fonts, many documents won't render correctly.

The size is what it is. There is no easy fix and splitting into dlls is just fake accounting.

[dungsaga]

The size of the portable release is 33% smaller. It looks like all the libraries are static linked and packed (with mpress or something).
It's nice to have a leaner release for portable use.

[GitHubRulesOK]

Considering MuPDF portable has less formats but is itself 41,326,080 bytes its amazing SumatraPDF is 1/3 rd as big
I grant you that pico is much smaller and was surprised until I remembered they download many support temporary functions all over the place. Several locations in users temp and in programdata too. still less diskspace but split files and usually empty folders even if report 0 bytes all use 4KB disk space sectors per filename even if a short link to home.

[dungsaga]

Yes, they put some files in %APPDATA%/Roaming but the additional size is less than 1MB.
And the folder C:\ProgramData\NCH Software\PicoPDF is empty.

The features of PicoPDF is quite basic, so I think that they can keep the total size to be ~3.6MB
When SumatraPDF 0.1 was release, it was only a bit more than 1MB.

UPDATED:
when using OCR feature for the first time, it downloads TesseractOCR to %APPDATA%/Roaming (almost 30MB).
So the total size of additional components is 30.5MB

But for normal editing, PicoPDF can even work without network connection.

UPDATED AGAIN:
I was wrong. PicoPDF downloads some files when I open a PDF file.
http://www.nch.com.au/components/zlib1v3.exe
http://www.nch.com.au/components/libjpeg.exe
http://www.nch.com.au/components/littlecms.exe
And when I use OCR feature, it downloads http://www.nch.com.au/components/tesseractocr3.exe

So, you still need internet connection when you open a PDF for the first time.
And it's weird that these components are not listed in http://www.nch.com.au/components/