Wolfram's marketing literature states that a compiled function may generate the dates for the years 1 through 5.7 million in a couple of seconds rather than in minutes (comparing to the "uncompiled implementation").
The given function in this link can be translated into Maple language as follows: 

(*
  Note that this is only a mathematical program that outputs some data,
   hence 'Easter(-2, 1)' will never return real Gregorian Easter dates!
*)
Easter:=proc(BEGIN::integer[4],END::integer[4],$)::Array(BEGIN..END,[integer[1..12],integer[1..31]]);# the parent function
	description "https://www.wolfram.com/language/12/code-compilation/compute-the-date-of-easter.html";
	local computus::procedure[[integer[1 .. 12], integer[1 .. 31]]](integer):=proc(Year::integer,` $`)::[integer[1..12],integer[1..31]];# the child function
		options threadsafe;
		local a::nonnegint,b::integer,c::nonnegint,d::integer,e::nonnegint,f::integer,g::nonnegint,h::nonnegint,i::nonnegint,j::nonnegint,k::nonnegint,Month::integer[1..12],Day::integer[1..31];
		(* For compatibility, when `Year` is nonpositive, the command `iquo` must be replaced with slower `floor`. *)
		if Year<=0 then
			a,b,c:=Year mod 19,floor(Year/100),Year mod 100;
			d,e,f:=floor(b/4),b mod 4,floor((8*b+13)/25);
			g,h,i:=19*a+b-d-f+15 mod 30,floor(c/4),c mod 4;
			j:=floor((a+11*g)/319);k:=2*e+2*h-i-g+j+32 mod 7;
			Month:=floor((g-j+k+90)/25);Day:=g-j+k+Month+19 mod 32
		else
			a,b,c:=irem(Year,19),iquo(Year,100),irem(Year,100):
			d,e,f:=iquo(b,4),irem(b,4),iquo(8*b+13,25);
			g,h,i:=irem(19*a+b-d-f+15,30),iquo(c,4),irem(c,4);
			j:=iquo(a+11*g,319);k:=irem(2*e+2*h-i-g+j+32,7);
			Month:=iquo(g-j+k+90,25);Day:=irem(g-j+k+Month+19,32)
		fi;
		[Month,Day]
	end;
	Array(BEGIN..END,computus)
end:

However, as "no nested procedures can be translated" to optimized native machine code (cf. ), executing Easter(1, 5700000) has to take at least two minutes: 

Is there some workaround that can provide improved performance for such a numerical procedure that contains a nested procedure? In other words, is it possible to produce the `result` (without modifying the algorithm) in two seconds in modern Maple as that Wolfram marketing literature claims?

The old question "Longest distance in a graph via Maple code" offers some general methods to find longest paths in a given graph, while for directed acyclic graphs, the longest paths can be found much more directly via built-in functions. However, it apprears that even for small dags, Maple cannot solve this in an acceptable time. In the following example, I'd like to count the number of nodes that on longest paths for certain source and target vertexes.
 

Download longest_paths_in_a_DAG.mw

Unfortunately, I have to wait for almost four minutes in the above instance. Can this task be done in 0.4s?

GraphTheory:-GraphEqual says that G₁ and G₂ are equal, but GraphTheory:-AllPairsDistance gives different results instead: 

Download allpairs.mw

So, which one is incorrect? Any reasons?

Some work, while others don't work. 
 

Download unable_to_sum.mw

How to explain this behavior?
I have read the help page, but I can not get the point.

Here is a symmetric matrix with three real parameters (`k__1`, `k__2`, and `k__3`).

mm:=<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
,0,0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0|0,0,1,0,0,0,0,0,0,0,0,0,0\
,k__3-1/2,0,k__3-1/2,0,0,0,0,0,0,0,0,-1/2,0,1-2*k__3,0,-1/\
2,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,\
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,\
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0|0,0,0,0,0,1,0,\
k__3,0,-1/2,0,0,0,0,0,0,0,0,0,k__3,0,-2*k__3,0,0,0,0,0,0,0\
,0,-1/2,0,0,0,0,0|0,0,0,0,0,0,-2*k__3,0,k__3-1,0,-1/2,0,0,\
0,0,0,0,0,0,0,k__3,0,1-2*k__3,0,0,0,0,0,0,0,0,k__1,0,0,0,0\
|0,0,0,0,0,k__3,0,1-4*k__3,0,k__3-1,0,0,0,0,0,0,0,0,0,(1-k\
__2)/2,0,k__3-1/2,0,0,0,0,0,0,0,0,1-2*k__3,0,0,0,0,0|0,0,0\
,0,0,0,k__3-1,0,1-4*k__3,0,k__3,0,0,0,0,0,0,0,0,0,k__3-1/2\
,0,(1-k__2)/2,0,0,0,0,0,0,0,0,1-2*k__3,0,0,0,0|0,0,0,0,0,-\
1/2,0,k__3-1,0,-2*k__3,0,0,0,0,0,0,0,0,0,1-2*k__3,0,k__3,0\
,0,0,0,0,0,0,0,k__1,0,0,0,0,0|0,0,0,0,0,0,-1/2,0,k__3,0,1,\
0,0,0,0,0,0,0,0,0,-2*k__3,0,k__3,0,0,0,0,0,0,0,0,-1/2,0,0,\
0,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,\
0,0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,-2*k__3,0,k__3,0\
,k__1,0,0,0,0,0,0,0,0,k__3-1,0,1-2*k__3,0,0,0,0,0,0,-1/2,0\
|0,0,k__3-1/2,0,0,0,0,0,0,0,0,0,0,k__2,0,-k__1+5*k__3-1/2,\
0,0,0,0,0,0,0,0,k__3-1/2,0,-k__1+5*k__3-1/2,0,1-2*k__3,0,0\
,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,k__3,0,1-2*k__3,0,k__3,\
0,0,0,0,0,0,0,0,k__3-1/2,0,k__3-1/2,0,0,0,0,0,0,-2*k__3,0|\
0,0,k__3-1/2,0,0,0,0,0,0,0,0,0,0,-k__1+5*k__3-1/2,0,k__2,0\
,0,0,0,0,0,0,0,1-2*k__3,0,-k__1+5*k__3-1/2,0,k__3-1/2,0,0,\
0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,k__1,0,k__3,0,-2*k__3,0,\
0,0,0,0,0,0,0,1-2*k__3,0,k__3-1,0,0,0,0,0,0,-1/2,0|0,0,0,0\
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
,0,0,0,0,0,0,0,0,0,0|0,0,0,0,0,k__3,0,(1-k__2)/2,0,1-2*k__\
3,0,0,0,0,0,0,0,0,0,1-4*k__3,0,k__3-1/2,0,0,0,0,0,0,0,0,k_\
_3-1,0,0,0,0,0|0,0,0,0,0,0,k__3,0,k__3-1/2,0,-2*k__3,0,0,0\
,0,0,0,0,0,0,1-2*k__3,0,k__3-1/2,0,0,0,0,0,0,0,0,k__3,0,0,\
0,0|0,0,0,0,0,-2*k__3,0,k__3-1/2,0,k__3,0,0,0,0,0,0,0,0,0,\
k__3-1/2,0,1-2*k__3,0,0,0,0,0,0,0,0,k__3,0,0,0,0,0|0,0,0,0\
,0,0,1-2*k__3,0,(1-k__2)/2,0,k__3,0,0,0,0,0,0,0,0,0,k__3-1\
/2,0,1-4*k__3,0,0,0,0,0,0,0,0,k__3-1,0,0,0,0|0,0,0,0,0,0,0\
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
|0,0,-1/2,0,0,0,0,0,0,0,0,0,0,k__3-1/2,0,1-2*k__3,0,0,0,0,\
0,0,0,0,1,0,k__3-1/2,0,-1/2,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,\
0,0,0,0,k__3-1,0,k__3-1/2,0,1-2*k__3,0,0,0,0,0,0,0,0,1-4*k\
__3,0,(1-k__2)/2,0,0,0,0,0,0,k__3,0|0,0,1-2*k__3,0,0,0,0,0\
,0,0,0,0,0,-k__1+5*k__3-1/2,0,-k__1+5*k__3-1/2,0,0,0,0,0,0\
,0,0,k__3-1/2,0,k__2,0,k__3-1/2,0,0,0,0,0,0,0|0,0,0,0,0,0,\
0,0,0,0,0,0,1-2*k__3,0,k__3-1/2,0,k__3-1,0,0,0,0,0,0,0,0,(\
1-k__2)/2,0,1-4*k__3,0,0,0,0,0,0,k__3,0|0,0,-1/2,0,0,0,0,0\
,0,0,0,0,0,1-2*k__3,0,k__3-1/2,0,0,0,0,0,0,0,0,-1/2,0,k__3\
-1/2,0,1,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0|0,0,0,0,0,-1/2,0,1-2*\
k__3,0,k__1,0,0,0,0,0,0,0,0,0,k__3-1,0,k__3,0,0,0,0,0,0,0,\
0,-2*k__3,0,0,0,0,0|0,0,0,0,0,0,k__1,0,1-2*k__3,0,-1/2,0,0\
,0,0,0,0,0,0,0,k__3,0,k__3-1,0,0,0,0,0,0,0,0,-2*k__3,0,0,0\
,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
,0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0,0,0,0,0,-1/\
2,0,-2*k__3,0,-1/2,0,0,0,0,0,0,0,0,k__3,0,k__3,0,0,0,0,0,0\
,1,0|0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>#assuming'real':
cc:={evalindets}(LinearAlgebra:-IsDefinite(mm,query='positive_semidefinite'),`and`,op):

As the title says, I hope to find some values satisfying andseq('cc') (so `mm` becomes positive semidefinite). Unfortunately, these don't work: 

# SMTLIB:-Satisfy(cc);
Optimization:-Maximize(0, cc, initialpoint = eval({k__ || (1 .. 3)} =~ 'rand(-2e1 .. 2e1)'()));
Error, (in Optimization:-NLPSolve) no feasible point found for the nonlinear constraints
timelimit(1e2, RealDomain:-solve(cc, [k__ || (1 .. 3)](*, 'maxsols' = 1*)));
Error, (in RegularChains:-SemiAlgebraicSetTools:-CylindricalAlgebraicDecompose) time expired

 Is there a way to do so as accurately (and precisely) as possible?