[vim/vim] recompress vim48x48.png to save space (PR #12709)
partev
$ advpng -z -4 -i 400 vim48x48.png
474 394 83% vim48x48.png
this resulted in 17% saving in space or 80 bytes
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/12709
Commit Summary
- 5c0e564 recompress vim48x48.png to save space
File Changes
(1 file)
- M runtime/vim48x48.png (0)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Eric Pruitt
The amount of resources consumed by making the pull request probably negates any advantages of saving 80 bytes. A file this small will consume less than one whole block on most filesystems which means there's effectively no benefit in shrinking it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
why is this done only for one of the .png files?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dominique Pellé
@ericpruitt wrote:
The amount of resources consumed by making the pull request probably negates any advantages of saving 80 bytes.
The PR is a one-time thing, whereas saving image size benefits many people many times.
Granted, it's a tiny saving, but why not.
But we should optimize all the png files, not just one.
Running optipng -o9 $(find . -name '*.png') saves overall ... 849 bytes (not much, but it has no drawbacks, so why not).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Eric Pruitt
The PR is a one-time thing, whereas saving image size benefits many people many times.
Except the PR will consume resources in being crawled by search engines, this message being transmitted to end users by email, the data stored in the database and later copied to offline systems for batch processing / backups, etc.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dominique Pellé
Running
optipng -o9 $(find . -name '*.png')saves overall ... 849 bytes (not much, but it has no drawbacks, so why not).
And running advpng -z -4 -i 400 $(find . -name '*.png') which uses zopfli saves more (1760 bytes).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
partev
I agree that doing only one .png file is maybe not worth doing, but re-compressing all of them saves 1760 bytes, which I think is worth it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> I agree that doing only one .png file is maybe not worth doing, but
> re-compressing all of them saves 1760 bytes, which I think is worth it.
$ ll *.png
-rw-rw-r-- 1 gary gary 454 Dec 7 2018 hi16-action-make.png
-rw-rw-r-- 1 gary gary 425 Dec 7 2018 hi22-action-make.png
-rw-rw-r-- 1 gary gary 226 Dec 7 2018 vim16x16.png
-rw-rw-r-- 1 gary gary 347 Dec 7 2018 vim32x32.png
-rw-rw-r-- 1 gary gary 474 Dec 7 2018 vim48x48.png
Note that each file is less than 512 bytes, the smallest block size
that I'm aware of. The block size on my hard drive is 4 kB, so each
file easily fits within one block.
$ du -sh *.png
4.0K hi16-action-make.png
4.0K hi22-action-make.png
4.0K vim16x16.png
4.0K vim32x32.png
4.0K vim48x48.png
So, compressing them will not have any effect at all on disk-space
consumption.
Something else you should consider is that, on my system,
/usr/local/share/vim/vim90 consumes 41 MB and the *vim* files in
/usr/local/bin consume 21 MB. Out of 62 MB, 1.7 kB is
nothing--definitely not worth doing _anything_ about.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dominique Pellé
Gary wrote:
Note that each file is less than 512 bytes, the smallest block size
that I'm aware of. The block size on my hard drive is 4 kB, so each
file easily fits within one block.
That's not always true. It depends on file systems. Some file systems
are optimized to store many tiny files inside their metatada i.e. in a block
which is normally not meant to be for the file content, hence avoiding
allocating a block much larger than the tiny file to store its content.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
partev
Closed #12709.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
partev
closing this pull request. If you change your mind you can always run advpng -z -4 -i 400 $(find . -name '*.png')
there are two more cases where 1.7 kB space saving is real and not impacted by filesystem block size.
- various Linux packages of vim (.deb, .rpm, .tar.gz, etc.) will be 1.7 kB smaller.
- various Linux container images (docker, LXC, etc.), most of which include vim by default.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Gary Johnson
> closing this pull request. If you change your mind you can always run advpng -z
> -4 -i 400 $(find . -name '*.png')
>
> there are two more cases where 1.7 kB space saving is real and not impacted by
> filesystem block size.
block size?
> 1. various Linux packages of vim (.deb, .rpm, .tar.gz, etc.) will be 1.7 kB
> smaller.
> 2. various Linux container images (docker, LXC, etc.), most of which include
> vim by default.
In these case, you won't save any space unless the number of blocks
occupied decreases, which is going to depend on how full the last
block is.
Again, this is a non-problem and not worth any effort to "fix".
Regards,
Gary
vim-dev ML
> closing this pull request. If you change your mind you can always run advpng -z
> -4 -i 400 $(find . -name '*.png')
>
> there are two more cases where 1.7 kB space saving is real and not impacted by
> filesystem block size.
What do you mean by that? How is the space used not impacted by the
block size?
> 1. various Linux packages of vim (.deb, .rpm, .tar.gz, etc.) will be 1.7 kB
> smaller.
> 2. various Linux container images (docker, LXC, etc.), most of which include
> vim by default.
In these case, you won't save any space unless the number of blocks
occupied decreases, which is going to depend on how full the last
block is.
Again, this is a non-problem and not worth any effort to "fix".
Regards,
Gary
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
partev
- various Linux packages of vim (.deb, .rpm, .tar.gz, etc.) will be 1.7 kB smaller. 2. various Linux container images (docker, LXC, etc.), most of which include vim by default.
In these case, you won't save any space unless the number of blocks occupied decreases, which is going to depend on how full the last block is.
yes, but when the number of blocks occupied decreases, you will save more than 1.7 kB in space. If you do the math, you will see that on average (sometimes more sometimes less) you will save exactly 1.7 kB.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Dominique Pellé
Again, this is a non-problem and not worth any effort to "fix".
It's a microoptimization but it's an optimization nonetheless, which costs nothing, so it should done.
For tar files, on average it saves memory.
I like the attitude of the SQLite developers, who wrote here https://www.sqlite.org/cpu.html :
Typical micro-optimizations reduce the number of CPU cycles by 0.1% or 0.05% or even less. Such improvements are impossible to measure with real-world timings. But hundreds or thousands of microoptimizations add up, resulting in measurable real-world performance gains.
There it was about CPU cycles, the but same applies to memory and I do see commits in SQLite that save just a few bytes of memory once in a while.
Earlier I wrote:
And running
advpng -z -4 -i 400 $(find . -name '*.png')which uses zopfli saves more (1760 bytes).
Actually it saves a bit more if we run optipng -o9 -strip all $(find . -name '*.png') before running advpng:
13888 bytes original
12641 bytes after `optipng -o9 -strip all $(find . -name '*.png')`
12104 bytes after `advpng -z -4 -i 400 $(find . -name '*.png')`
Saving: 1784 bytes (-12.8%)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.