Re: [boost] [gil io_new review] Reading images from in-memorysources

Subject: Re: [boost] [gil io_new review] Reading images from in-memorysources
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-12-07 12:12:43

"Kenny Riddile" <kfriddile_at_[hidden]> wrote in message 
news:idj944$lk7$1_at_dough.gmane.org...
> Yes, implementations of a spec are free to implement their requirements 
> however they like (assuming no other requirements are violated).  That 
> being said, I just looked at the implementation of array_source and it 
> appears that none of the data in the array is being copied.

Yes, AFAICT also, the array_source implementation does not copy the input 
data (in fact, even if the documentation does not state it explicitly, it 
would IMO be common sense to assume so...as if it did actually copy the data 
this would constitute a performance bug by any standard)...

However, redundant copying is only part of the issue here (in some use cases 
possibly even a less important one) as boost::iostreams::array_source still 
uses the std::iostreams infrastructure which means that includes all of its 
redundant horrors (locales, mutexes, virtual functions, RTTI, dynamic memory 
allocation, exceptions, transformations......)...
Simply looking at/stepping through the release-mode generated assembly for 
merely the boost::iostreams::stream<array_source> constructor will make most 
heads dizzy...

A proper (and zero overhead at that) way to model an in memory image would 
be a plain boost::iterator_range<> ... Not only because it is free of all 
the iostream monstrosities but because with backends like LibJPEG and 
LibTIFF reading an image from a boost::iterator_range<> can be accomplished 
without the LibXXX backend making a single seek/read callback (back to the 
GIL.IO 'device' that is in this case a boost::iterator_range<> or a 
transparent wrapper around it) because it already has all the data readily 
available...
Additionally with the boost::iterator_range<> approach it is easy to add 
memory mapped file support for reading images (where the input image/file is 
again represented with a plain boost::iterator_range<> with all the benefits 
outlined above)...

 -- 
"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