If it takes more then about 0.5 seconds more to transmit the large file then the small file, then (on my system - which is an older ultrabook, so quite slow thus giving a conservative scenatio), it is better to send the more highly compressed file. This will, of-course, depend on the speed of your connection, the distance to the server and the size of the file. So a highly compressed file appears to be about 10 slower to decompress then a lightly compressed file.īut, this does not take into account the time taken to download the file. The results were as follows: Converting the small file 200 times - 1 minute, 16.07 secondsĬonverting the large file 200 times - 1 minute, 22.39 seconds In each case I ran the script quickly and aborted it after a few seconds so any system caching could come into effect before running the full test, thus reducing the impact of disk io (and my computer happens to use SSD which also minimizes that impact. I then wrote a script to convert the image from png to tif (on the assumption that TIF is a relatively uncompressed file format so quite fast) 200 times and timed the output. The image was something I grabbed off Google and was a picture of a star cluster. The highly compressed file was 1.8 megs, the lightly compressed png was 4.7 megs. I found a large PNG file online, opened it in GIMP and saved 2 versions of it - 1 with compression level 9 (very small) and 1 with compression level 0 (large). I ran a little experiment for you - Its not perfect, but it should give some insites into the scope of the problem. Generally, the fewer bits it reads in, the faster the PNG decompression is likely to be. When an algorithm works harder, it might find more or longer matches, which usually result in better compression, but it will take longer to do it.īy contrast, the decompression algorithm is very simple and doesn't have to do much work - it just decodes the stream in a fairly linear fashion, and it doesn't have to search for matches because they are provided by the compressor - it just looks up the length/distance codes provided to it. Algorithms vary, but many of them can be made to work harder or go faster using certain parameters. The compressor has to use an algorithm to look for matching sequences before it can encode them. (It could also encode it as A B C D E F D.) A B C D E F A B C A B C D could be encoded as A B C D E F. One way DEFLATE saves space is to encode recurring byte sequences by just providing a runlength, and an distance back to where it previously appeared in the stream. The PNG compresses image data with DEFLATE (the same algorithm used in zlib and PKZIP). If you want to minimise the filesize when saving a PNG file, the sacrifice comes in the time it takes to compress the file. with a smaller file size) should generally take less time to load than the same image with a larger size. The huge line-art that I referred to was mostly desktop wallpapers like the ones at, but various posters, videogame resources, and other things could also fit that description.īetter-compressed images (i.e. Windows users might not notice this, but most icons used by the desktop environment are stored with PNG compression, and dozens of them need to be rendered when the system starts. I don't know if this information affects the question, but I am wondering about this in relation to both icon-type files (which are small because they contain few pixels) and huge line-art files (which are small because they compress their pixels very effectively).ĮDIT: In response to the answers I've been getting, I want to note that this is not strictly a network issue. We all know that more-compressed PNG images take longer to compress, but do they take longer to decompress? Technically that would be trivial too, but I've wondered about it for a long time. When I create PNG files with very small disk size, I tend to wonder if the file size becomes less important than the time viewers would need to decompress the image.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |