There are several aspects to improving performance here.

One aspect is the Maple level overhead that occurs before the external call to the compiled cuhre library. Another aspect is the what optimizations can be gained by parallelization.

It's often a good idea to make sure that the serial version runs as fast as possible before trying to paralellize.

Let's consider Library-level overhead first.
 - Don't load all of Student:-MultivariableCalculus. If you need one of its exported commands (and it appears that you don't) then call by its explicit long-form name.
 - Ensure that the integrand is evalhf'able (yours was, so good).
 - Use the operator form calling sequence, rather than expression form, for the integrand. (That saves Maple from having to figure out just how to call `makeproc`.)

I am not sure that the usual entry-points of evalf(Int(...) or int(...,numeric) are thread-safe at the Library level, even when using operator form. At least once I got a seg-fault from the external routine, which I suspect is because the threads were mashing data at the Library level (but I'm not 100% sure why).

If I get time I may look at what overhead could be avoided by calling `evalf/int/MultipleInt`:-cuhre directly with operator form integrand, or possibly even duplicate its methodology. I suspect that Library-level overhead is a measurable portion even for the best timing I show below.

As far as parallelization goes, there is still the distinction between the timing cost of the external code and the preliminary Library-level lead-up the external call.
 - The call_external to the cuhre library may be thread-blocking (I haven't checked yet) and if so then there may also be even greater parallelization benefit in toggling that off (presuming it's thread-safe).
 - There are some small float[8] Arrays that get created each time, and it's plausible that making them be thread-local to a rewritten module implementation of `evalf/int/MultipleInt`:-cuhre could allow them to be be re-used and save on memory management overhead.
 - For this kind of work I'm often only satisfied when I see the amount of garbage collection ("memory used") get very small. At N=30000 it is still 500MB in the best below. The total gc real-time may be only 0.25-0.5sec but I'd prefer it were closer to 0sec.

Anyway, there's lots to consider. Maybe I'll find some spare time for it.

Your original with operator form: thread_mp_ac1.mw

Here's a larger example (starting from Carl's example), with various flavors of operator versus expression form. Run in 64bit Linux Maple 2019.0 on a quad-core i5.

Using Threads:-Add along with operator form integrands has the best performance of these.

Download cuhreperf.mw

(It's more polite to include a link to your uploaded worksheet, so that nobody else has to type it all out.)

There are a variety of possible ways.

There's less need for extra care and effort if you know that j+1 won't appear anywhere but as an index of T.

Download isol_index.mw

Here is something you might be able to work with.

The basic idea is this. If both sides of the equation are products of terms then do as follows:
 - freeze the multiplicands of both sides
 - divide both sides by the intersection of those multiplicands
 - thaw and simplify

It's quite possible that the freezing/thawing might not be necessary. I put them in to strive for generality. I would not be surprised if there were examples where it helped and other examples where it hindered.

I used simplify(expand(...),size) up front to try and get both sides to be simplified products. But for other examples that might be helped by other means, eg. factor.

By the way, why do you start out with (black) active sum calls instead of (gray) inert Sum calls. Those sum calls don't seem to compute closed forms (ie, they return as unevaluated sum calls). But every time you manipulate or simplify the expressions you have to wait while it tries in vain to compute closed forms for the newer sum calls.

Download common_factors_ac.mw

Download JSON_example.mw

The red spam square appears visible to you because you have elevated moderator status on this site. Most members do not.

The red box only shows for postings by new members which have not yet received vote-ups (and possible Answers, I'm not sure).

If -- as moderator -- you were to remove a posting using thd red spam box then that member's account would also be deactivated.

I delete (as spam) postings from one or two advertisers (cleaning products, rivet wholesellers, etc.) each day. This forum used to be inundated with such. It was a big problem.

There is also a mechanism for moderators to delete unanswered single items ( as "Inappropriate", "Duplicate", etc) without affecting the poster's membership status.

You added material since first asking. I wrote this to address the original bit, where you seem to be asking to reverse the "product rule". First I yank off the extra 1/r^2 factor. Then I integrate wrt r, then do "by parts", and then differentiate wrt r. And then I multiply by the extra factor.

I don't know how much of that you want to automate.

I have not yet looked at the addendum.

Download rev_prodrule.mw

The following does a "hot" edit of VectorCalculus:-D, replacing two uses of apply with direct function application.

It seems to behave so far with Maple 2016.2 through 2019.0.  Let me know if not.

Download VCDhotedit.mw

The regression bug in apply has been reported, along with the unnecessary use of apply in VectorCalculus:-D.

This is just for general interest. I expect the OP may be busy implementing his own Emacs Lisp-based CAS (since Maple, Mathematica, Maxima, Sympy, and Axiom have all failed him) so as to finish implementing his significant improvement over FFT.

It seems that plot is having difficulty recognizing or handling some jump discontinuities (eg, at x=0.0) when that is used as the left end-point of the plotted domain.

Here I'm using Maple 12.02 to try and match your setup.

For three of the plots, if I supply a slightly wider domain (range for x) then the discont=true option seems to kick in ok and the jump is not displayed.

For plt02 I had to use an even wider range, and that one may be suffering a slightly different issue.

ps. I changed the B value for plt11 from 21 to 1, to agree with the other in that group. Perhaps a typo.

It might be possible that in modern Maple the issues could be handled by using discont=[fdiscont=[...]] with some judicious choice of options. I didn't fiddle with that because Maple 12 doesn't offer it.

I see that you've ignored my previous suggestion to compute all these plots much faster using fsolve to solve all the roots at once (per x value). Oh well.

file_discont_ac.mw

Is this adequate for your purposes?

with(inttrans):
sinc := x->piecewise(x = 0, 1, sin(Pi*x)/x/Pi):
S := x->sinc(x):
SE := unapply(simplify(sinc(x)*exp(-x^2)),x);
abs(fourier(convert(SE(x),Heaviside),x,s));
plot(%,s=0..5);

The original definition of SE := x->sinc(x)*exp(-x^2) gets the same plot, if used above instead. The main difference was the conversion of the piecewise to Heaviside before applying fourier. Hopefully I have not misunderstood.

I don't really understand the point of constructing an operator for SE just to plot SE(x), when an expression would do. Maybe you need/prefer an operator later on...

[edit] I see that Carl posted his working revision only moments after I posted this; doubtless we were composing at the same time. The only difference being that Carl put the Heaviside into the defn of SE while I left SE with a piecewise and only converted for the purpose of calling fourier.[/edit]

It looks like gfun:-listtorec can handle this.

You can also use rsolve(...,makeproc) to get a procedure.

Or you can construct a procedure from the recursive formula (with option remember for better efficiency). I could cut and paste the recursive formula obtained from listtorec, but for fun I build it programmatically below.

Download listtorec.mw

I converted your Post to a Question. Please submit your future questions a Questions rather than Posts.

Download Jac_proc.mw

It's not entirely clear to me from your question whether you want a Vector of procedures or a Vector-valued procedure (ie. a single procedure which returns a Vector of the derivatives evaluated at subsequent input points). Your earlier Question about a bug under assume and with VectorCalculus loaded looked as if you wanted a Vector of procedures.

But often a Vector-valued procedure is convenient to utilize subsequently. Hence my use of codegen[JACOBIAN] below.

For example (and accepting a procedure with an arbitrary number of arguments):

Download Jac_proc_alt.mw

You haven't shown the full example that demands loading all of VectorCalculus, or using assume instead of say assuming. So it's not possible to properly address subsequent -- but as yet unstated -- issues you may have.

However,

Download VCD.mw

eqs := {a + b + c = 1,
        a^2 + b^2 + c^2 = 2,
        a^3 + b^3 + c^3 = 3}:

a^4 + b^4 + c^4 = eval(R,solve(eqs union {a^4 + b^4 + c^4=R}));

                        4    4    4   25
                       a  + b  + c  = --
                                      6 
a^5 + b^5 + c^5 = eval(R,solve(eqs union {a^5 + b^5 + c^5=R}));

                         5    5    5    
                        a  + b  + c  = 6

I recall having the same questions, when ColorTools first appeared.

At that time I was able to find, in the internal code, a transformation Matrix corresponding to D50 (which confirmed a few empirical tests). In a subsequent release I noticed that had changed to correspond to D65. But there seems to be little or no documentation about that.

And I believe that by "RGB" the ColorTools package means sRGB, not a wider gamut like Adobe RGB. (Some monitors allow one to toggle amongst such. But I have never tested what effect that might have on what the Maple GUI shows. A missing bit of knowledge might be which the Java GUI's renderer is using.)

Another interesting detail might be just how ColorTools makes certains colors (when converted to RGB from, say, Lab or Luv) "displayable". It's not always clear how it may regress back to the displayable gamut, ie. does it regress linearly back to the white point, or what?

Eventually I wrote my own converters (also via XYZ colorspace) because I wanted them to Compile and be fast on datatype=float[8] rtables representing many colors (eg, images). That gives me full control about the mathematical conversion, though details of the GUI's renderer may still be a missing link in the chain, if I want to visualize.

What form do you want for the results?

Download trighsimp.mw