> On Jun 28, 2024, at 3:15 AM, Neville Smythe via use-livecode
> wrote:
>
> I have a solution or at least a workaround
Hi, Neville. You may find a worthwhile improvement in speed if you avoid
referring to the Unicode lines by their line numbers (as in "line k of fff").
Here's a way:
functi
On 2024-06-29 08:53, Neville Smythe via use-livecode wrote:
Is it not the case that the processing time for looping over the number
of lines and getting the k-th line in each iteration, for some
arbitrary k, going to be
Order(N^2) * C * T
where
N = the number of lines in the text
C = the nu
Thanks Mark for pointing me (as ever) in the right direction, away from the red
herring but to the hidden inner loop entailed in evaluating
line k of fff
A bit embarrassing because I was party to the discussion some time ago about
the slowness of lineOffset when working with unicode text.
And
I love using red herring in conversations. Most people don’t know what that is,
so they can’t contradict me! :-)
Bob S
On Jun 28, 2024, at 5:02 AM, Mark Waddingham via use-livecode
wrote:
so thinking this is regex related is a red-herring.
___
use
On 2024-06-28 11:15, Neville Smythe via use-livecode wrote:
In my last epistle I mentioned the repeat loop had only 32 iterations.
Much more relevant of course is the inner loop on the number of lines
of the data variable fff. In this case fff had 1760 lines. So the total
possible number of ite
In my last epistle I mentioned the repeat loop had only 32 iterations. Much
more relevant of course is the inner loop on the number of lines of the data
variable fff. In this case fff had 1760 lines. So the total possible number of
iterations was around 3 to 5, getting up there but still
Neville Smythe wrote:
> The same handler, same code, in a previous version of the
> offending stack, takes 0.06 seconds, both in the current
> 9.6.12 IDE, and using a standalone compiled under a
> previous LC version.
In your previous message yesterday you wrote:
> So I have done something to the
Thank Craig for your suggestion about replacing the Preferences file. No luck.
I am down to going through line by line to find what process is taking so much
time. I am now totally confused by finding that a handler which calls no
handlers of mine, and simply has a repeat loop over just 32 shor
Have you tried trashing the LC preferences?
Have you tried the recent stack with a different data stack, or perhaps one
with less data?
Craig
> On Jun 26, 2024, at 4:35 AM, Neville Smythe via use-livecode
> wrote:
>
> I am plagued by a new problem which has arisen in an old stack that I have
I am plagued by a new problem which has arisen in an old stack that I have been
using for years with hundreds of modifications over that time. It was still
working well until suddenly in the last few week most of its data processing
handlers have slowed to a crawl. A button that gathers text dat
10 matches
Mail list logo
