Large processing tables

[Kenneth Brody]

Quoting Fairlight (Sun, 25 Feb 2007 23:02:40 -0500):

[...]
> > On Fri, Feb 23, 2007 at 09:50:51AM -0500, Kenneth Brody wrote:
> > > Pre-5.6, filePro processing was limited to 128K of compiled code.
> > > This was increased to 2MB in the 5.6 release.  It's possible that
> > > you have run into some problem related to this.
>
> Can I just ask why there's a limit at all?
>
> I don't get it.  From my design standpoint, if you run up against legacy
> limits and have to rewrite code, why not just be cost-effective and
> effort-effective and rewrite it with full unlimited dynamic memory
> allocation (to the limits of system resources available) instead of just
> raising them a bit?

This isn't a memory allocation issue.  It's a limit imposed by the
fact that the filePro VM uses 16 bit offsets.  Changing this would
not be a minor undertaking, and would probably break backwards
compatibility.  (At a minimum, it would prevent new rcabes from
compiling for older versions of filePro, unless it were to include
both compilers.)

The engine was enhanced some years ago to allow it to use two
separate 64K chunks for these 16-bit offsets, hence the older 128K
limit.  With 5.6, this was enhanced to allow it to keep track of
up to 32 64K segments, for the new 2MB limit.

[...]

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com