"read...until <string>" -- buffer size

[Kay C Lan]

On Wed, Aug 6, 2014 at 5:16 AM, Alex Tweedly <alex at tweedly.net> wrote:
>
> LC is supposed to be an easy to use language/system....

>     "report of a bug due to unacceptable performance",
> and it should just say something like "Make this work at acceptable speed so
> it can be used" :-).

I tend to agree with Alex on this one, but if the route cause is
buffer size, and it's discovered that it's currently optimised for the
400KB Floppies of the HyperCard days then I'd suggest the solution is
not to manually set the buffer size but to have LC find the optimum
for you.

With the current variety of disk sizes, proportion of disk empty, rpm
and even if it's mechanical or SSD, what ever you discover to be the
optimum on your machine is unlikely to be the optimum on Richmond's
heroic G3 tray loading iMac running 10.3. I'd even suggest taht
whatever you find is the optimum today, may not be the optimum in a
year. I've bench tested many HDs and there seems to be quite a variety
of factors that determine the file size that achieves the fastest
read/write times, and quite a variety in those file sizes, so I'm sure
whether it's buffer size, something else, or a combinateion, the same
would be true for 'read from file'.

Wouldn't it be better if you could, in an openStack or similar:

get maxReadSpeed()
--runs a suite of tests to determine the settings that achieves
maximum read from file speed.
--then sets these as defaults which will be used by read (and other?) functions
--only needs to run once
--automatically reset to pre-LC settings when you Quit LC

And from then on use the standard read functions.

So a bug report to fix the current speed, then if it's found that
speed improvements can be had by adjusting system/LC internal
settings, an enhancement request for an LC function that would
determine and set these as default. This would ensure whether you're
running a nearly full 250GB 5400rpm HD or a basically empty 750GB SSD,
' read from file tMyFile until CR' will work faster than anything you
can mangle using multiple lines of LC code.