Re: [boost] GIL io_new review

Subject: Re: [boost] GIL io_new review
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2011-01-16 08:32:34

"Domagoj Saric" <domagoj.saric_at_[hidden]> wrote in message 
news:ie84mm$hun$1_at_dough.gmane.org...
>
> "Lubomir Bourdev" <lbourdev_at_[hidden]> wrote in message
> news:C2C30445-BD2B-496F-B079-D7966943B269_at_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