"Domagoj Saric" <domagoj.saric@littleendian.com> wrote in message news:ie84mm$hun$1@dough.gmane.org...
"Lubomir Bourdev" <lbourdev@adobe.com> wrote in message news:C2C30445-BD2B-496F-B079-D7966943B269@adobe.com... << First of all, I don't believe your tests represent real use scenarios. If you loop over the same image, the image gets into the OS cache and therefore the I/O access bottleneck is no longer there. It is not typically the case that the image is in the OS cache before you start reading it. A better test case is to have many images and do a single loop over them. So I cannot trust the 30% number that you report. My prediction is that if you do it for fresh images the differences will be far smaller than 30%.
Yes, the test I used is purely synthetic and hardly represents any real use case. However it is good for measuring/pointing at the overall overhead/'fat' that each of the libraries induces which is important to consider for any library (in the light of the 'global picture argument' I voiced earlier)...
Actually I take this back...i.e. I (re)claim that the test posted is fully relevant and not that far from real use cases on several grounds: - the overhead of decompression/decoding of (PNG and JPEG) images (+ the calls/access to low level OS/kernel APIs) is perfectly sufficient to test whether the injudicious use of STL containers, memory allocations and copying is in fact a 'negligible' overhead (as was claimed and proven false by the test) - decoding images without physical disk access/cached images is a frequently encountered scenario for example for anyone looking through their collection of digital photos where any decent photo viewing application will try to load-ahead images and when the delay between images is still apparent even without any significant disk activity (plus the scenario where you move backwards through already seen and thus cached images) - decoding images without any disk access/in-memory images is also a valid scenario (for example small static/binary resource images such as application icons, backgrounds...)... - and finally, again:
Regardless of the above, the argument of 'shadowing by expensive IO/OS/backend calls/operations' is still fallacious as previously explained...
-- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman