This isn't particularly complicated. Varying the span generates graphs that are smooth or have an obvious bug. Not sure why.

This also happens if you vary the C_I_CentLim or the C_Inventory. I created this example so it is clearly happening.
The graph gets a sharp jag down, then returns to normal.

Something weird with density of points? I played with it for hours and can't get it to go away.
=============================================
restart;
L := 0;
C_Inventory := 1500;
C_I_CentLim := 0.001;
C_I_StartLim := C_Inventory*C_I_CentLim;
C_InV := Matrix(1000, 3);  # This is so you  can see values created only bobble slightly where the graph has a giant deviation.
iCounter := 0;
P_ScLdt := proc(t) local x, k; global L, C_Inventory, iCounter, C_InV; x := 0; k := 0.08; iCounter := iCounter + 1; L := C_Inventory*C_I_CentLim; x := 4.8 + L/(1 + exp(-k*(t - 2060))) + 0.050; C_InV[iCounter, 1] := L; C_InV[iCounter, 2] := C_Inventory; C_InV[iCounter, 3] := x; if 0 < x then C_Inventory := C_Inventory - x; return x; else return 0; end if; end proc;

# Show results 1800-2100  Problem.
pP_ScLdt := plot('P_ScLdt'(x), x = 1800 .. 2100, linestyle = dash, color = red, thickness = 3, axis = [gridlines = [colour = black, majorlines = 2]], legend = "Pg");

# Re-initialize.
L := 0;
C_Inventory := 1500;
C_I_CentLim := 0.001;
C_I_StartLim := C_Inventory*C_I_CentLim;
C_InV := Matrix(1000, 3);
iCounter := 0;
# Show  that problem happens with a little shorter span
pP_ScLdt := plot('P_ScLdt'(x), x = 1850 .. 2100, linestyle = solid, color = black, thickness = 1, axis = [gridlines = [colour = black, majorlines = 2]], legend = "Pg");

# Re-initialize
L := 0;
C_Inventory := 1500;
C_I_CentLim := 0.001;
C_I_StartLim := C_Inventory*C_I_CentLim;
C_InV := Matrix(1000, 3);
iCounter := 0;
# Show problem goes away with a different interval 1900-2200
pP_ScLdt := plot('P_ScLdt'(x), x = 1900 .. 2200, linestyle = dash, color = blue, thickness = 3, axis = [gridlines = [colour = black, majorlines = 2]], legend = "Pg");

# Re-initialize
L := 0;
C_Inventory := 1500;
C_I_CentLim := 0.001;
C_I_StartLim := C_Inventory*C_I_CentLim;
C_InV := Matrix(1000, 3);
iCounter := 0;
# Enlarge the working interval of 1900-2200 to 1900-2300 and the problem returns, in a different place.
pP_ScLdt := plot('P_ScLdt'(x), x = 1900 .. 2300, linestyle = dash, color = blue, thickness = 3, axis = [gridlines = [colour = black, majorlines = 2]], legend = "Pg");

# Re-initialize
L := 0;
C_Inventory := 2000;
C_I_CentLim := 0.001;
C_I_StartLim := C_Inventory*C_I_CentLim;
C_InV := Matrix(1000, 3);
iCounter := 0;

# Enlarge the interval and it causes a larger set of jaggie deviations.
pP_ScLdt := plot('P_ScLdt'(x), x = 1800 .. 2800, linestyle = solid, color = blue, thickness = 1, axis = [gridlines = [colour = black, majorlines = 2]], legend = "Pg");

X := vector([seq(x, x = 1 .. 5)]);
Y := vector([seq(x, x = 6 .. 10)]);
X[1];
Y[1];
Yfactor := evalf(X[`1`])/Y[`1`];
evalf(Yfactor);
                      X := [1, 2, 3, 4, 5]

                     Y := [6, 7, 8, 9, 10]

                               1

                               6

                                         X[1]
                        Yfactor := -------
                                         Y[1]

                              X[1]
                              ----
                              Y[1]

m := 1;
X := vector([seq(x, x = 1 .. 5)]);
Y := vector([seq(x, x = 6 .. 10)]);
Yfactor := X[m]/Y[m];
evalf(Yfactor);
                             m := 1

                      X := [1, 2, 3, 4, 5]

                     Y := [6, 7, 8, 9, 10]

                                           1
                          Yfactor := ---
                                           6

                          0.1666666667

Strange behavior. I don't know if this can be made to work.  I replaced an equation with an interpolation object, f(x).

tInt := int(f, 133  .. 134, numeric);
tInt := 324.95206944305  <= Computes a result. I

tInt := int(f, 133  .. 312, numeric);
tInt:= int(fproc, 133. .. 312.) <= Won't compute it. The interpolation object has 3051 points, so that's not the problem. The name "fproc" is not something I have in my  code, just the name, "f".

If I try to make the  integral just slightly more complex by  passing a variable in, it doesn't work at all. This was to see if I could integrate with a varying divisor: f(x)/(x+1)
int(f(x), x = 133 .. 134, numeric); 

Error, (in int) wrong number (or type) of arguments: invalid options or option values passed to definite integration. <=

A fallback  was to use summation, but that doesn't work at all, same typ of error as the Error for int. (Not shown.)

So my fallback is to use a for loop to sum the set. The for loops produce another set of values, and I think I have to make interpolation objects for that as well. And so on. I really  was expecting  Maple to handle this better.

I want to do some memory management in Maple for large arrays.

To clarify this question: What do I have to do in Maple to free memory allocated to an array? The indications I have are that memory probably is not freed, but rather a new variable of null is created that replaces the old one, but the old one is still sitting around.

I have reported this to Maplesoft. There is a problem (on LInux 20.2) that has to do with java. I have (well, I had) a large project. Around 1500 lines when I cut and pasted into a word processor. (No, I was not editing in the word processor, I just needed a way to put a number on the size that was better than, "quite large". )

I do my editing in 2D math. The other is not an option, and I kind of doubt it would matter.

There is a problem in 2022,  in which,  after working in the editor for 3-5 hours, it gets very slow. CPU use will go into the 80% range. Java will have 1.7 GB or RAM allocated to it. The editor  becomes impossible to use. The only cure is to save the file, then re-open it after shutting down Maple. If Java goes away in system monitor (Linux version of Taskmanager) then it will work fine when it comes back. This appears to me to be a bug in handling of java, in which Maple never lets go of memory, and some piece of code goes off into all that RAM to do something. I have waited as long as half an hour. That time I gave up and killed the java task which ended Maple.

Just now, what prompted this post, in addition, is that when I brought Maple back up for the (2-3 times per day complete restart due to this problem) the file I had just saved is now corrupted, and truncated. A lot of work is gone, and no way to retrieve it I know of. The file is now less than half the size it was (43% of the size of the previous version number).

I told support that this release is acting like beta software, despite being the regular release.

Be careful. Increment your saved versions of .mw files regularly. Save regularly. Expect problems.

Configuration: Intel i7 CPU, 64 GB RAM. Note that earlier versions of Maple sometimes got memory use up to 12 GB on other sheets. I have not noticed what Java was using prior to this.

I noticed that someone changed this to a "performance" tag. It is not really about performance. This shows up as the editor is a bit slow, and then suddenly the editor is off in the weeds for a while. This is a serious memory management problem. It is also a bug that killed a day's work, and if I hadn't been lucky more than a day. Maple should not destroy files when it writes them out.

Please don't arbitrarily recategorize a bug without fully reading the problem.