Re: [Boost-users] Intoductory Boost Presentation

From: Jon Kalb (Kalb_at_[hidden])
Date: 2003-11-11 16:21:30

On 11/10/03 5:49 PM, "Darryl Green" <Darryl.Green_at_[hidden]> wrote:

> Hi Jon,
> 
>> -----Original Message-----
>> From: Jon Kalb [mailto:Kalb_at_[hidden]]
>> Sent: Tuesday, 11 November 2003 11:16 AM
>> To: Boost Users
>> Subject: Re: [Boost-users] Intoductory Boost Presentation
>> 
>> 
>> On 11/9/03 8:06 PM, "Matthew S Trentini" <matt_s_trentini_at_[hidden]>
>> wrote:
>> 
>>> Heya Everyone,
>>> 
>>> I recently gave a presentation to my work colleagues on the
>> wonders of the
>>> Boost library.
> [snip]
>> 
>> Matt, 
>> 
>> I don't know if you plan to keep this updated, but here is
>> some feedback
>> from a co-worker. I have not verified his findings.
>> 
> [snip]
>>> 
>>> The rest of the pages have the classic boost downfall: they
>>> don't discuss any of the pitfalls, performance problems, or
>>> code bloat issues, which frankly, seem like the "crazy aunt
>>> in the basement" of boost.
>> 
> 
> I don't suppose your co-worker would like to enlighten us about these
> issues/areas with which he obviously has some expertise and considers
> the documentation (and the code?) deficient? That would be as useful as
> Matt's overview could be to those just getting into/considering using
> boost libs. As it stands, all that the above statement adds is FUD.

I passed on my friend's comments without attribution because I didn't ask
his permission and I don't think he really intended the comments for so
large an audience. His comments were directed to our co-workers and we know
a little about some of the research that he has done on some of the Boost
libraries. With that audience it isn't exactly FUD.

I will forward this message to him and ask if he wants to comment more
specifically, but I'll give you one example that he found. I don't recall
the exact number, but he found that a function call using Boost::function
generated about 20K of code (in our development environment). I realize that
in a day when gigabyte hard drives are a dime a dozen it seems miserly to
worry about 20K, but that is for *one function call*. I don't think he
benchmarked it to see how long it takes to execute this code, but still I
think he has a point when he talks about code bloat.

I also think he has a point about discussing the performance trade-off issue
of each library. When the STL was first introduced, it was so revolutionary
that it was given a very skeptical reception. But most people were won over.
The power/overhead ratio was very favorable and it looked like compilers
would likely improve in ways that would make it even more favorable.

Now we are comfortable with template libraries and are less skeptical of new
ones. But every library has some overhead cost and has some applications for
which it is ill-suited. We need to evaluate each library on its own merits
and never assume that because one was accepted in Boost it has some magic
property that means there are no performance trade-offs or that the
performance profiles of all Boost libraries are similar.

Suppose users determine that Boost::function (I'm just picking on this as an
example) is great for creating flexible interfaces, but should be avoided
for any inner-loop use or where code size is at a premium. That doesn't make
the library worthless, in fact, adding advice about the best situations to
use the library enhances its value.

-- 
Jon Kalb
Kalb_at_[hidden]