Hi,
I just committed into CVS a major change how frequent numeric objects
(`flyweights') are set up. Until now we had functions like `const ex
& _ex1(void)' that always returned the same ex representing numeric 1.
This speeds up the library considerably because ex::compare can be
restricted to pointer comparison. However, the object inside that
function was constructed on first use of the function as a static
variable and thus came the two thorns in my side:
1) Ugly syntax: Several hundreds of occurrences of _ex0(), _ex1(),
etc, resulting in fishbone Lisp-style.
2) The function call occuring there could not be avoided, resulting
in degraded speed.
I have now figured a way how to avoid these problems. Similarly to
section 27.4.2.1.6 in the C++ standard, where cout and friends are set
up, we now allocate a static initializer object in each object file
#include'ing <ginac/ex.h>. The first of these constructors being
called takes care of setting up the flyweights `const numeric
*_num1_p' on the heap and marking them as `dynallocated' [*]. Then,
in file utils.cpp, we initialize both
const numeric &_num1 = *_num1_p;
const ex _ex1 = _num1;
Wherever we have been writing _ex1() we can thus simply write _ex1
internally. Same applies to _num1() which is now called _num1. As
advertised, the change makes parts of the library more readable and
the compiled library slightly smaller and about 5-15% faster.
I checked that it still works with Cint (5.15.14) and some other
unmodified apps. Pearu, could you please check with PyGiNaC? I
understand that Python sets up Flyweights from 0 to 100 as well but I
cannot see that the two are tied together in any way. Therefore you
hopefully aren't affected at all.
Regards
-richy.
[*] This assures ex' ctor from basic& does not copy it again.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>