fpxfer export to a file - permissions/ownership

[Fairlight]

On Mon, Sep 18, 2017 at 01:49:23PM -0400, Richard Kreiss thus spoke:
> 
> I am hoping that fpTech will take advantage of the added memory space and
> add some runtime functionality which would allow clerk, report and dxmaint
> to make efficient use of the multiple cores processors have today.  One
> gaming article I read recently mentioned 16 core processors for gaming
> machines.  Today's 64 bit operating systems can make efficient use of the
> processor cores so why not filePro?

Won't happen without a huge rewrite.  filePro binaries are single-threaded.
Games are (usually) multi-threaded.  The last single-core game I knew which
was worth a damn was Grim Dawn, which is only single-CPU/single-core
because it inherited the Titan Quest engine, purchased from the original
studio by the guy who left to found his own studio after the disbanding of
the original.

Going from single-threaded to multi-threaded is not an easy migration.  You
not only have to plan out what the cores will do and how to best make use
of them, but implement the IPC to get all the threads speaking and
coordinating properly.

Honestly, *most* of what you do in filePro is not really something
which requires multi-threaded processing.  Most of your bottlenecks are
disk-bound, not CPU-bound or RAM-bound.  I don't even know if report would
benefit from multi-threading for the sort/selection phase.  If it's simply
using the indexes on disk, I doubt it.  Then it, too, is disk-bound.

Making clerk multi-threaded would be a waste of time.  It spends most of
its time idle.  I'd implement select()-based I/O before even considering
going multi-threaded; it would be of far greater benefit, especially in
those situations (like simple errors or msgbox displays) where polling
loops are used on STDIN.  Those should be select()-based, with timeouts.
That would solve so many problems.

> > Why would you need drop if the system was faster?  I would anticipate
> needing
> > drop if a system was -slower-.
> 
> OK - this will be a long explanation.
> 
> environment.  After checking the source code for the browse lookup function,
> it was found that to allow for the quick redisplay of the browse lines, the
> record numbers were cashed.  What was happening was the billing clerk would

Hasn't it been repeatedly stated that record numbers are unreliable?  This
is a surprising find, if you're saying it's internal to filePro.

> I am running into a perceived speed issue at a clients in how fast filePro
> selects records and begins printing.  This is from that order file and the
> output uses a dash lookup to select records to print(in the timed case, 25
> detail lines).  It is doing this in a file will well over 20 million records
> and doing it in under 5 seconds from record selection to completed print
> job.  I timed it the other day so my numbers are accurate.  Their complaint
> is the record selection is not fast enough.  These are network PC's running
> across gigabit Ethernet.
> 
> The way that this operation could be speeded up would be to install a small
> SSD and set filePro's temp directory to that drive.  That would be faster
> than writing to a mechanical drive.

Why not just go all the way, and use a ramdisk?  :)  (We'll table the
discussion of how to achieve persistence between reboots for that
scenario.)

m->
-- 
Audio panton, cogito singularis.