[edited] I've put my earlier Answer's commentary, into this attached copy of my earlier worksheet. That took about 7 minutes to find a point that attained about 1e-3 as largest equation residual of the problem cast as a global optimization problem. It turned out that minimum point could be used by fsolve to quickly find an actual root. kompletter_nachbau_v0_acer_fsolve_commented.mw

The methodology includes eliminating h[0] by equating the rhs's of two pairs from the three equations containing that that variable (after isolating for it). The variable p was treated specially, and bounds supplied for all remaining variables.

Later, it occurred to me that fsolve could be attempted for every p value attempted, following the inner DirectSearch:-SolveEquations step. I then discovered that the first p value tried was succeeding, for a variety of fixed p values within some bounds. This cut the total computation time down from about 7 minutes to about 7 seconds. And it allows finding multiple distinct roots. kompletter_nachbau_v0_acer_fsolve_3.mw

Then it occurred to me that perhaps having a starting point (for fsolve) that was close to globally optimal in the (sum of squares of residuals) optimization problem might not be necessary for fsolve to succeed in finding an actual root. So here is a revision where SolveEquations provides a feasible (all equations real-valued) starting point for fsolve, where that point may not be particularly close to optimal. The evaluationlimit option is passed to SolveEquations with a relatively small value of 1000. And this subsequently produces an actual root from fsolve. And there are no ranges supplied for any of the variables. And the whole thing takes 1.5 seconds on a fast machine.

(I've put the equations into the Startup Code region, so they don't take up space here.)
Download kompletter_nachbau_v0_DS_fsolve.mw

Firstly, you need to upload an actual Worksheet or Document, if you want us to be able to see precisely what you have. Use the big green arrow in the Mapleprimes editor pane, to upload and attach.

You need to fix your brackets, which don't always match in several of your examples.

Eg. the call to the eval command in your second proc has mismatched round brackets. It's missing the closing bracket.

And in one of your calls to the procedure you have mismatched square brackets.

There are other syntax problems, some possibly related to attempts at getting implicit multiplication. But it's impossible to be sure without an actual upload.

If 2D Input in a Document is too much trouble for you, you can change the preference to be 1D plaintext Maple notation in  Worksheet. (I suggest this, for new users.)

eq := a*b=a*c;

                        eq := a b = a c

gcd(rhs(eq), lhs(eq))

                               a

map(`/`, eq, gcd(rhs(eq), lhs(eq)));

                             b = c

The assignment W:=V does not make W into a distinct and independent copy of V. It makes W a reference to V. And so, as written, your procedure acts in-place on V.

Change that line to W:=copy(V) if you do not want the operations on entries of W to be operations on V.

See also Section 6.7 of the Programming Manual, Using Data Structures with Procedures.

Download awass_copy_vs_inplace.mw

Why presume that the plot command is thread-safe? (It isn't.) Most Library commands are not.

There are many ways for a Library procedure (or module) to be thread-unsafe. (Use of declared globals in procedures is just one of several ways.)

As of Maple 2018, there is no working mechanism to query for thread-safety of an arbitrary Library procedure.

Nor is there any mechanism to work around partial thread-safety by blocking only the thread-unsafe bits.

If such mechanisms existed then there would likely be a great deal more use of the Threads package by other stock commands.

You could also try Grid:-Seq , but be forewarned that it has even worse overhead than Threads, so is less suitable for fine-grained lower level parallelism. And even Threads is not very good there.

But you might be able to effectively distribute calls to a proc that produced many plots of the total sequence. Suppose you wanted 100 frames altogether. You may be able to get a reasonable improvement by calling Grid:-Seq on a call to a custom procedure that individually constructed say 1/4 or 1/2 of those 100 for each call.

If you have executed something like with(IrisData), so that the name Species is rebound, then you may need to reference the global in order to make the kind of indexed reference you have in your posted image of a call to GridPlot.

That is, use the name  IrisData[':-Species']  instead of just IrisData[Species] .

At the end of this attachment I explain the same thing, using the `Sepal Length` example which throws an error when your attached Worksheet is executed as it is. That is, you can always use IrisData[':-`Sepal Length`'] , whether you have or have not executed with(IrisData).

Download IRISdata_ac.mw

Sometimes the assuming command can get some desired results, without the awkwardness of managing names whose previous assumption have been cleared.

Download clear_assmp.mw

[edited] I may well have misinterpreted this Question earlier.

Originally I interpreted the question as being about why the timing differences varied, using the same mechanism.

Carl's response below makes me think that the OP may instead be asking why the timing differnce using time[real] varies from that using ProcessClock. So now this Answer has been rewritten.

But I'd still say that comparing such very small timings isn't generally sound. Moreover, in the posted examples the overhead of the time-queries, and the order of their execution, and the printing of output and communication with the GUI, may all interfere. So I don't think that this is a robust testing example for very small timings.

In an earlier Question I recemmended that the OP use the time[real] command, for finding real-world wall clock elapsed time. I'll stand by that. I don't advocate using ProcessClock for that purpose, as I don't think that it's suitable for the job.

To compare wall-clock time, use the command time[real]() at start and at finish, and then take the difference.

This could measure how long it takes a student to respond, between steps or in total, in your interactive application.

Try this.

animation_CommandPlease_ac.mw

There are various keywords for controlling an animation within a Plot Component. These are documented on the PlotComponent Help page.

[edited] You did not say, at all, what kind of animation of sin(x) (or whatever) that you wanted. So I made one up. Tom made up another. The key thing is the use of the SetProperty command and the play keyword, I think. That's is the purpose of this line of code that I wrote at the end of the Button's action code,
   SetProperty("Plot0", ':-play', true, ':-refresh'=true);

[edited] The originating point, where the period cycles, is different. In a sense the cross "crosses" there, since it overlaps with itself. I may need to re-implement the approach.

Download intersect2.mw

If I understand you, the query is about deriving/constructing the Sum (since we could always just enter it by hand, but that's not exciting).

I'm not aware of anything like a Split (in SumTools or wherever). So that part is manual (but a procedure for it could be written easily, for re-use).

I would not be surprised it were relatively easy to fix up the sign on -a, or expand wrt a instead, or fix up the binomial to be the prettier equivalent.

Download binomialSum.mw

Why I'd agree with Kitonum that is can often be a way to go with such things, 

verify(2*cos(phi)^2-1, cos(2*phi), simplify);

                   true

Note that verify,equal may rely upon signum, and,

signum(2*cos(phi)^2-1 - cos(2*phi));

              /          2                 \
        signum\2 cos(phi)  - 1 - cos(2 phi)/

simplify(signum(2*cos(phi)^2-1 - cos(2*phi)));

                   0

Here is something, under assumptions like k::posint, x::real, etc.

(Btw, are those Mathematica results valid everywhere? I don't feel like typing them in.)

Download int_k.mw

Download 2d_inert_star_M18.mw