You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
julia> using JET, Groebner, AbstractAlgebra
julia> _, x = QQ["x"]
(Univariate polynomial ring in x over rationals, x)
julia> @report_optgroebner([x^3-x^2-1])
The @report_opt command prints so many entries that I can't even scroll up to the beginning. I'm guessing that improving the situation here would tremendously improve performance.
The text was updated successfully, but these errors were encountered:
Previously, I have tried to reduce dynamic dispatch in Groebner a bit. My experience at that time was that if the types in the main "number-crunching" routines were inferred successfully, then dynamic dispatch in other parts of the code did not hinder runtime performance too much.
I may be wrong about that. Seeing the number of errors reported by @report_opt, it is possible that I missed something, and revisiting this issue in a systematical manner can be useful.
By the way, as I understand, some of the runtime dispatch comes from other modules. For example, if I do
using JET, Groebner, AbstractAlgebra
R, x = QQ["x"]
@report_opt target_modules=(Groebner,) groebner([x +1])
the list seems to be much shorter
EDIT: but still, @report_opt groebner([x + 1]) contains useful info that is not included when using target_modules=(Groebner,). So, thanks for bringing this to my attenrion
The
@report_opt
command prints so many entries that I can't even scroll up to the beginning. I'm guessing that improving the situation here would tremendously improve performance.The text was updated successfully, but these errors were encountered: