fpxfer export to a file - permissions/ownership

Mon Sep 18 19:18:25 PDT 2017

Top Post,

Mark, I was not looking for filePro to become multi-threated.  All I was think was that when someone open multiple sessions of filePro, if clerk is started, it would check to see which core had the lease activity and load in that core.  The same for report or dxmaint.  These are the three programs which normally require the most computing power. 

What this might do is allow Windows users the ability to push reports and index maintenance into background as the *nix users can.

I realize that making filePro multithreaded would require a major rewrite.  This might not such be a bad thing as it would make it possible to add a lot of functionality that is currently not present.  Though it may break the backward compatibility.  A rewrite such as this might also allow for the adjustment of the license manager to be session aware and allow for one user to run multiple sessions only using 1 license seat.  

If I have 4 sessions open on my computer, why should all of them load in the same core?  This will most likely happen sometime in the future if filePro is to survive.  They are making it easier to have filePro talk to SQL databases and vice-versa.  The adding of PDF printing is allowing filePro to work with dumb windows printers.  Too bad they didn't license PrintWizard as it is easy to implement in filePro.

I find outputting to a PDF an advantage and money saver in that I am using less paper and ink/toner when creating and testing new outputs.  I can sent them to a PDF, the look at them.  If there is a problem or I just don't like the way it look, I can quickly make a change.  Also, I have the ability to print out one or two pages or a range of pages instead of a complete report.

Richard 

> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Fairlight via
> Filepro-list
> Sent: Monday, September 18, 2017 3:00 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: fpxfer export to a file - permissions/ownership
> 
> 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.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 16892 bytes
Desc: not available
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20170919/06a4fb43/attachment.bin>