Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-03-24 01:00:16


> On Tue, Mar 02, 2004 at 09:33:40AM -0500, Gennadiy Rozental wrote:
> > if you could provide an examples of intended usage for this class to
address
> > real-life problems with performance comparison with corresponding
imperative
> > analog, that would be good enough to satisfy me on the topic.
>
> Here is a quick example (based on an idea from an earlier thread) which
> you may or may not find interesting.
>
> The "problem" is to code up some const forward iterators for
> preorder/inorder traversals of this simple data structure:

> The moral I am trying to sell is that lazy evaluation here is a win for
> the programmer; the code is shorter and clearer.
>
> Of course, there's a catch: performance. The FC++ version runs about
> 3-4 slower than the other version.

[...]

> I think it's valuable to have the trade-off available, so that you can
> choose between raw performance and code that's easier to read/understand.
>
> {
> cerr << "pre_tree_iterator" << endl;
> Timer timer; // please use your own timing mechanism here
> pre_tree_iterator<Tree<int> > end = pre_end_tree(tree);
> for( pre_tree_iterator<Tree<int> > i = pre_begin_tree(tree);
> i != end; ++i )
> cout << *i << " ";
> cout << endl;
> cerr << timer.ms_since_start() << endl;
> }

You must be kidding me! You measure performance based on ostream
operation??!!!

Actually if you write a proper performnce test (what I did), You will see
that your version runs 300 (three hundred) times slower. And this is for
trivial iteration over trivial data structure. Let me repeat that there is
no practical value in component having 300 times abstraction price. As for
clarity of the code I beleve that there are a lot of C++ programmers that
will fould your code much more puzzling (C style implementation that you
presented could be easily enhanced without significant loss of performance
to be much more supportable and easy to read). Also it's my gut feeling that
your solution is not scalable - try add more complexity to the problem
performance will worsen exponentially.

The moral I am trying to sell is that lazy evaluation (in your sence) is
never win for C++ programmer, but just an academic example what could be
done with C++.

Gennadiy.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk