| | <<<Back 1 day (to 2018/11/07) | 20181108 |
| sebras | chrisl: ok, so I took two JPEG from here: https://visibleearth.nasa.gov/view.php?id=73751 | 14:28.49 |
| | chrisl: one 2Mbyte and one 35 Mbyte | 14:29.00 |
| kens | Are they baseline JPEG | 14:29.11 |
| | ? | 14:29.14 |
| sebras | next I used mutool create to create PDFs for me for each of those JPEGs | 14:29.14 |
| kens | Oh OK | 14:29.19 |
| sebras | I don't know what baseline JPEGs are. :) | 14:29.28 |
| kens | Its in the spec | 14:29.44 |
| sebras | I would assume that mutool create just copies those JPEGs directly into the PDF without checking anything. | 14:30.09 |
| kens | Hmm, that would be less than ideal | 14:30.19 |
| | But if Acrobat can open them then I guess its OK | 14:30.27 |
| sebras | next I coaxed gs to compile with libjpeg-turbo, which require me to replace the guts of base/gsjconf.h since the existing defines for whatever reason was incompatible with libjpeg-turbo. in this instance I simply copied the contents of my Debian-system-installed /usr/include/x86_64-linux-gnu/jconfig.h (yes, I was also surprised that there are ARCH-specific headers...). | 14:32.32 |
| | with one gs built with our standard libjpeg-9c and one built using libjpeg-turbo-whateverversion I got these results: | 14:33.00 |
| | http://paste.debian.net/plainh/e56f55bf | 14:33.04 |
| kens | So its faster | 14:33.49 |
| sebras | I think I'm testing version 1.5.2-2+b1 at least. | 14:33.50 |
| | seems like it. | 14:33.55 |
| | however I did have to install nasm just to get the library to compile. | 14:34.17 |
| kens | Yep | 14:34.22 |
| sebras | that's not a surprise, but it means gs would have a new dependency. | 14:34.28 |
| kens | That's one of Chris' complaints | 14:34.30 |
| sebras | I'll look into whether these JPEGs conform to the specification baseline. | 14:34.59 |
| kens | I expect they probably do | 14:35.14 |
| sebras | at least the performance difference would warrant the time looking into that. :) | 14:35.28 |
| | I wanted BIG JPEGs so the difference would be visible. | 14:35.47 |
| kens | That's not very big really, we've seen bigger | 14:36.18 |
| | > 100MB | 14:36.23 |
| sebras | kens: ok, are they available somewhere? | 14:36.56 |
| kens | Well, in the test suite I guess | 14:37.10 |
| sebras | kens: might be an interesting data point. | 14:37.11 |
| kens | TBH I try not to put files like that in the tests cos thhey are big | 14:39.22 |
| chrisl | sebras: I'd rather have representative files with DCT encoded images in them. jpegturbo might take 50 per cent of the time to decode an image, but if it's only 20% of the execution time for 90% of "real" files, it's not (IMHO) worth the effort | 14:59.21 |
| sebras | chrisl: right, also because libjpeg-turbo is dependent on the computer being used we'd also need to think about what platform it should be tested on. | 15:50.57 |
| | chrisl: so far I simply tested on my laptop. | 15:51.13 |
| | chrisl: I didn't change the CPU governor, so perhaps the CPU frequrency is varying wildly. | 15:51.51 |
| | chrisl: but if this simple test proved that the difference is in the 1-3% range then we'd already know that this is not worthwhile testing at all. | 15:52.22 |
| chrisl | sebras: That's true. I wasn't criticising your approach - it at least makes it easy so see when you *are* using jpegturbo | 15:53.27 |
| | I just don't think it's worth the hassle, the extra dependency (which will be a *huge* pain on Windows), to only see worthwhile improvements in a smal fraction of niche jobs | 15:54.43 |
| sebras | chrisl: right. | 15:55.22 |
| | Forward 1 day (to 2018/11/09)>>> | |
Log of #ghostscript at irc.freenode.net.