Akim Demaille
Hi Joaquin!
Le 14 oct. 2014 à 11:34, Joaquin M Lopez Munoz
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