The FORM polynomial routines are written in apparently copy semantics rather than move semantics, because it was written in C++98 and the move semantics was not supported at the language level. This means that there would be many unnecessary memory copies. I just made patches to apply move semantics to poly. Unfortunately the result of a polyratfun intensive benchmark https://gist.github.com/tueda/8cabf511573b115b9c17a7a181bf0248 suggests that such a copying cost is negligible. (Actually the most time-consuming part of this benchmark is addition of big integers.)
Anyway, If someone finds a case where copy semantics seems to cause a significant loss of the performance, the following patches can be tried and would be merged to the master branch:
The FORM polynomial routines are written in apparently copy semantics rather than move semantics, because it was written in C++98 and the move semantics was not supported at the language level. This means that there would be many unnecessary memory copies. I just made patches to apply move semantics to
poly. Unfortunately the result of a polyratfun intensive benchmark https://gist.github.com/tueda/8cabf511573b115b9c17a7a181bf0248 suggests that such a copying cost is negligible. (Actually the most time-consuming part of this benchmark is addition of big integers.)Anyway, If someone finds a case where copy semantics seems to cause a significant loss of the performance, the following patches can be tried and would be merged to the master branch:
polyif the compiler is in the C++11 mode: https://github.com/tueda/form/commit/77183d775b93b66333f7cfabd8ad3093929a22d5