Sorting an array

[Fairlight]

On Thu, May 19, 2016 at 12:39:40PM -0400, Jose Lerebours via Filepro-list thus spoke:
> Mark,
> 
> Tell me again how running a shell script is a "pure-fP" solution?

Quoting JPR:

::' This is a proforma subroutine to sort a filePro array.:
::' It works on UNIX/Linux or Windows (NTFS filesystems,:
::'   because it uses long file names for temporary files,:
::'   but can be edited to work with 8.3 file names).:
::'@(#) (C)2005 Bob Stockler - Free use allowed so long as this line
remains:
::'@(#) sort subroutine - sort an array (write a temporary file and sort it):

Look at the syntax with the colon placement and the apostrophe-based
commenting.  It's -clearly- an ABE=ASCII PRC, -not- shell scripting.

> While at it, tell me how it can be done without running "system" nor
> "user" commands or any "new shell" triggers?

See above.  The only thing I would add is that I tried to get at JPR's ftp
site, and it's immediately closing connection on both ncftp and Firefox
(with an ftp:// URI), so currently I don't think anyone can get at the PRC
until JP fixes his ftp site.  JP?

> Also, can you provide a resource measure of how the shell script is
> less of a hog than a PHP script?

Sure I can.  I only have to reiterate what I said last night.  When you use
SYSTEM, system(2) is used to handle the actual exec, so that your shell
metacharacters are translated as expected.  The system(2) function achieves
this by -invoking bash-.  This means you have:

clerk|report
   |--> bash
      |--> php

If you have a shell script which is already written in bash, you have:

clerk|report
   |--> bash

The only externals which should be called from that bash would be
non-builtins (cat, ls, etc.).

Now, bash is 775KB.  PHP on the system I'm currently looking at is 7.3MB.

That's an extra 7.3MB -per invocation-.  Multiply by potentially hundreds
of concurrent web requests going through to clerk or report and then
systeming back out to PHP just to do a simple sort.  Say you had 100
concurrent runs.  That's an extra 730MB of RAM -wasted-, JUST for php.
Then there would be the extra 7.75MB of wasted RAM taken in bash shells
sitting as a shim layer between clerk|report and php itself, which you
cannot bypass because system(2) invokes them.

In practise, the numbers are slightly lower, as the VMM will actually
reduce the amount taken via shared memory.  In practise, the same php image
was taking about 218MB per invocation of -actual- non-shared RAM.  That's
still tremendously wasteful on a busy system, if you don't need to invoke
the waste of resources.

It's not just RAM, either.  Do an `strace -f` of your filePro run, and use
the -o option to log to a file.  Notice that whenever bash and php are
invoked, the first things they do are load all their shared libraries,
which in general goes through LDPATH entry by entry, appending the shared
library name in question, and doing a stat() to see if it's there.
Granted, 99% of that is likely cached, and CPU speeds these days make it a
bit of a nit, but you're eating a -tonne- of redundant syscalls just
starting up a dynamically linked binary.  It may not take -much- time;
certainly not on a quiescent system.  On a busy system stretched to near
its capacity, it can mean the difference between fluidity and feeling
unresponsive, when iterated over dozens-to-hundreds of these.

> Finally, if the script has to create a file to sort the file and
> then read the file, is this a "shameful" approach?

If it could have been done relatively easily as a purely internal solution,
and that solution performs within adequate-to-excellent performance, I
would say, "Absolutely."

mark->