@2cUniverse You can never make a valid comparison between two measurements both of which have been rounded down to 0. You must either use a finer measuring instrument, or increase the scale of the problem until the instrument returns positive values. The latter is usually easier in Maple.

**iremFrac2a:=proc(n,d, b)
local r1,r,i,li:
li:=NULL:
r:= irem(n*b,d):
if NumberTheory:-AreCoprime(d,b) then
while true do
r1:= irem(b*r,d):
li:=li,[[r,r],[r,r1]],[[r,r1],[r1,r1]]:
if r1=n then break fi:
r:=r1:
end do:
else print("Denom-Base not coprime "): return [] fi:
[li]
end proc
:
iremFrac2b:= proc(n, d, b) local N:= irem(n,d), r:= irem(N*b, d), s;
[if igcd(b,d) = 1 then
(do [[r,r], [r, (s:= irem(b*r, d))]], [[r,s], [s,s]] until (r:= s)=N)
else
print("Denom-Base not coprime")
fi]
end proc
:
d:= nextprime(2^17): b:= irem(rand(), d);**
b := 116956
**(L1, CT1, RT1):= CodeTools:-Usage(
iremFrac2a(1, d, b), output= [output, cputime, realtime]
)[]:**
memory used=14.24GiB, alloc change=-32.00MiB,
cpu time=5.09m, real time=79.49s, gc time=4.93m
**(L2, CT2, RT2):= CodeTools:-Usage(
iremFrac2b(1, d, b), output= [output, cputime, realtime]
)[]:**
memory used=14.89MiB, alloc change=0 bytes,
cpu time=172.00ms, real time=165.00ms, gc time=0ns
**#Verify that computed results are equal:**
**evalb(L1 = L2);**
true
**#time ratios (real and CPU):**
**RT1/RT2, CT1/CT2;**
481.7333333, 1776.529070

To be fair, those ratios are not as extreme if I increase the scale of the problem "horizontally" (i.e., smaller test cases but more of them) rather than "vertically" (i.e., a single large test case), as above. I'll explain why in a moment.

**d:= nextprime(2^10): b:= irem~(['rand()'$64], d);**
b := [173, 917, 905, 706, 476, 906, 759, 1001, 827, 720, 297, 35,
933, 582, 61, 289, 139, 245, 817, 496, 11, 477, 1001, 541, 824,
911, 787, 901, 990, 853, 562, 160, 248, 313, 631, 873, 630,
281, 565, 282, 85, 761, 311, 1021, 475, 123, 593, 632, 209,
683, 931, 296, 348, 381, 890, 772, 720, 565, 529, 277, 861,
286, 147, 912]
**(L1, CT1, RT1):= CodeTools:-Usage(
iremFrac2a~(1, d, b), output= [output, cputime, realtime]
)[]:**
memory used=283.35MiB, alloc change=8.00KiB,
cpu time=6.34s, real time=1.70s, gc time=6.02s
**(L2, CT2, RT2):= CodeTools:-Usage(
iremFrac2b~(1, d, b), output= [output, cputime, realtime]
)[]:**
memory used=13.95MiB, alloc change=0 bytes,
cpu time=172.00ms, real time=172.00ms, gc time=0ns
**#Verify that computed results are equal:**
**evalb(L1 = L2);**
true
**#time ratios (real and CPU):
RT1/RT2, CT1/CT2;**
9.877906977, 36.88372093

The reason is that when you create a sequence (or list or set) by appending to an existing sequence, each assignment reconstructs the entire sequence. Of course, the time for *each* such reconstruction is proportional to the length of the sequence. Thus, the time for the whole loop (just for this reconstruction minutiae, not for the actual desired computation) is proportional to the *square* of the number of loop iterations. Using the standard asymtotic-order ("big O") notation, we say that the time for this process is O(n^2) (where n is the number of iterations). Assuming that the actual computation time for each sequence element is independent of its position in the sequence (which is very often the case, and it's certainly true in this case), that time is O(n) in total. It's mathematically certain that there's a value of n, say n_c, such that the O(n^2) process will dominate the O(n) process for all n > n_c. In more-technical mathematical language, for any A > 0, B > 0,

limit(A*n^2 / (B*n) , n= infinity) = infinity.