[Octave-bug-tracker] [bug #53012] Performance of sort on complex values

[Michael Leitner]

Follow-up Comment #4, bug #53012 (project octave):

Yes, it seems you are right, sortrows needs more internal storage than what it
needs for the output (this should have been obvious to me). When I limit the
available virtual memory for the octave process to 2 GB via bash's ulimit, I
can allocate a matrix of dimensions Nx2 with N up to 8.5e7, but I can generate
the permutation vector via sortrows only for N=4e7. So it seems that the
memory consumption would be 16* N for the input, 16* N for the temporary
[abs() arg()], and about 16* N for the generation of the permutation vector
(including already the output). That is, going via sortrows the peak
consumption is about three times the size of the input, while via the native
sort it is about two times. 

Probably this cannot be significantly improved anymore, so we have to stick
with the time/space dilemma.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53012>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/