While some channel types are classes, a built-in type such as ‘unsigned char’ is a valid channel. We have to be careful so we don’t slow down operations on common 8-bit images. I think it is safe to replace “Channel” with “const Channel” but “const Channel&” has a size of a pointer and this is far bigger than unsigned char. Perhaps to do this right one needs to create a metafunction that returns the type by value or by const reference, whichever is faster. Lubomir From: Eloi Du Bois [mailto:eloi.du.bois@gmail.com] Sent: Friday, November 27, 2009 3:37 PM To: boost-users@lists.boost.org Cc: Lubomir Bourdev Subject: Re: [Boost-users] [GIL] Performance warning... I am not an expert but I think on primitive types, there is no need to put a reference (and it may slows down the process). But the line I mentioned before concern a channel object, and I think this object stores many datas (maybe a byte array ?). 2009/11/28 Christian Henning mailto:chhenning@gmail.com> Lubomir, looking at the default_channel_converter the channels already arrive as a const reference. All I did was to make sure they are still const references in the channel_converter functions. In all cases the source channels should at least be const. Which allows for more compiler optimizations. I did run the performance test in gil_test suite and the changes were marginal. Some tests were faster some were slower after the change. Christian On Fri, Nov 27, 2009 at 6:13 PM, Lubomir Bourdev mailto:lbourdev@adobe.com> wrote:

This was done on purpose. I don't know if it still holds, but it used to be that a const reference to a simple type like an int or char is slower than passing the type by value. This is the same reason most STL algorithms take iterators by value. If you want to make this change it is important to verify that performance of simple built-in channel types is not adversely affected.

Lubomir

On 11/27/09 12:17 PM, "Christian Henning" mailto:chhenning@gmail.com> wrote:

...

Hi Eloi, you're correct and I'll fix that. I can even make it const reference. Running the test shows no real difference but that might be only because no expensive channels are being used.

I'll commit the changes asap.

Lubomir, please review the changes if your time allows. Affected files are channel_algorithm.hpp and gil_concept.hpp.

Thanks, Christian

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.orgmailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi guys, I'll look into the call_traits metafunction tomorrow. I can also write a simple test that would measure potential overhead. Thanks for the input! Christian 2009/11/27 Agustín K-ballo Bergé :

Lubomir Bourdev escribió:

...

While some channel types are classes, a built-in type such as ‘unsigned char’ is a valid channel. We have to be careful so we don’t slow down operations on common 8-bit images. I think it is safe to replace “Channel” with “const Channel” but “const Channel&” has a size of a pointer and this is far bigger than unsigned char.

Perhaps to do this right one needs to create a metafunction that returns the type by value or by const reference, whichever is faster.

Lubomir

call_traits< T >::param_type does that.

"Defines a type that represents the "best" way to pass a parameter of type T to a function." http://www.boost.org/doc/libs/1_41_0/libs/utility/call_traits.htm

Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users