Boost logo

Boost :

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
> "Lubomir Bourdev" <lbourdev_at_[hidden]> wrote in message
> <<
> 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 

Boost list run by bdawes at, gregod at, cpdaniel at, john at