Re: [Boost-users] Flyweight: wrapping shared_ptr

Subject: Re: [Boost-users] Flyweight: wrapping shared_ptr
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2014-10-22 10:24:55

Akim Demaille <akim <at> lrde.epita.fr> writes:

> 
> Hi Joaquin!
> 
> Le 14 oct. 2014 Ã  11:34, Joaquin M Lopez Munoz <joaquin <at> tid.es> a
> écrit :
> > 
> > Hashing and equality comparison of flyweight'd expressions is going
> > to be blazingly fast as compared with recursive non-flyweight'd
> > versions.
> 
> Yes, that's where I expect to get most of my speed up.  However,
> for deep expressions, ordered containers were quite fast, more
> than hashes, since often the comparison does not go deep inside.
> So I'll have to bench whether to stick to ordered containers, or
> move to unordered ones.

I'm not sure I'm following you here... Comparison and hashing of flyweights
is blazingly fast *and* does not depend on the expression depth of
the flyweight'd values --it does not depend on the values at all, in fact.
If you mean that flyweight *creation*, which requires hashing the
expression (but only one level deep) with the default hash-based
Boost.Flyweight factory, is slower than using a std::set-based factory,
well, profiling can tell.

> 
> > Also, have you considered memoizing eval(), either by
> > storing eval result in the expressions themselves or using something
> > like the following?
> 
> On this regard, I don't like Boost.Flyweight too much, and
> prefer to cache myself.  Using an unordered_map for instance,
> in a functor, make memory-management cheap and easy.  AFAICT,
> there is nothing comparable with Flyweight: either I pay a useless
> ref-counting, or I leak, right?

Yes, you're right. There's no such a feature as a run-time flyweight
factory, so I think your home-made approach is going to be more
convenient.

Joaquín M López Muñoz
Telefónica