For instance, given nine integer x₁, x₂, …, x₉ satisfying x₁, x₂, …, x₉ ≥ -5 and x₁³＋x₂³＋…＋x₉³＝0, the goal is to maximize x₁ + x₂ + … + x₉. However, according to Optimization/Options,  is not accepted by the Optimization:-Maximize command. A probable method is applying floor into the optimization variables; unfortunately, I can only get: Error, (in Optimization:-NLPSolve) no improved point could be found. 

(*restart;*)
vars := [x || (1 .. 9)]:
Optimization:-Maximize(`?()`(`+`, floor~(expr)), [add(floor~(expr) ^~ 3) = 0, expr[] >=~ -5], initialpoint = (unapply~(expr) =~ rand(-5 .. 10))()); # Alternatives to exhaustive search?
Error, (in Optimization:-NLPSolve) no improved point could be found

Is there any workaround to solve this problem? 

I think that the following worksheet is self-explaining: 
 

Download funm.mws

How do you confirm the validity of the last output? 

> op(3, eval(LinearAlgebra:-MatrixFunction));
 = 
  Copyright (c) 2002 Waterloo Maple Inc. All rights reserved.

And does this mean that LinearAlgebra['MatrixFunction'] is so out-dated that the return value is less effective in certain cases?

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?