Subject: Re: [boost] [gil][io_ew] performance test
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2011-01-30 11:52:06
"Christian Henning" <chhenning_at_[hidden]> wrote in message
> Hi Domagoj, good to hear back from you. Hope all is well.
Hi, thanks, well other than a little insomnia all is well ;-D
> On Sun, Jan 16, 2011 at 8:58 AM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>> "Christian Henning" <chhenning_at_[hidden]> wrote in message
>>> Hi there, I did a little update to include more files. Now I have
>>> 26580 jpeg files distributed over 10 folders. I also tried to reduce
>>> the number of image memory allocation by reusing the same image over
>>> and over again.
>> But you still used boost::filesystem which is also not the most
>> thing in the Universe (for example, simply adding its cpp files to my
>> project added ~150kB to the release binary...also between the "if (
>> fs::is_directory( dir_path ) )" line and the first read_image() call I
>> counted 16 memory allocations and 6 memory allocations between each
>> subsequent call to read_image()...)...
> Maybe so, but I use filesystem in both tests. Meaning the overhead is
> prevalent in my IO and your IO.
? That exactly is the problem...by adding constant overhead to all
benchmarked cases you diminish/'dampen' the resulting difference
percentage...(otherwise you could have left the image allocation inside the
> How do you count these memory allocations?
A breakpoint in ::operator new() ?
> I did some changes in
> io_new. No strings anymore, for example.
The allocations I mentioned were (only the ones) done in/by
>> Your test description is also missing relevant information, such as the
>> machine's hardware and software configuration, third party library
>> and compiler and linker options used to build them and the test
> Sorry, my bad. I use a pretty powerful box with 2 Intel Xeon E5630 and
> 12GB of RAM. For compiling I used VS2010 on Windows 7. For boost I'm
> using some trunk version for the 1.46 release.
3rd party lib versions, build options, image(s) used (e.g. as I've described
in the post to Mateusz)...
But, the bottom line is why are we still wasting time with this (comparing
io_new and io2) when the difference (at least regarding efficiency) is
If we are going to make a 'merge' as was previously speculated (although I
don't actually see how is that possible considering the substantial
difference in interfaces and the fact that io_new has already been accepted
based on its present interface) it makes no sense to fix what is deficient
in io_new if there is a better counterpart in io2 and vice verse...
-- "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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk