Refactoring is your friend / moving from 6.x to 9.x
Kay C Lan
lan.kc.macmail at gmail.com
Fri Jan 4 09:03:24 CET 2019
On Fri, Jan 4, 2019 at 6:03 PM Richard Gaskin via use-livecode
<use-livecode at lists.runrev.com> wrote:
> Is there an actual list of concrete concerns here that the team may be
> able to take action on ...
I think the closest would be:
>Not yet fixable for me:
>Array operations on larger data sets still slower than they were
Which leads me to the post titled: On Performance of Array Access
posted 31 Aug 2018 relating specifically to large array data sets.
>The wise Mark Wa (on a 2018MBP) wrote:
>Generally, I don't tend to like to 'jump the gun' on anything related to
>optimization lest it is not what it seems when running in the real world
His scripts used for the tests are all public, repeatable and
objective, but if you don't want to bother finding that Post here are
the results (PR6671 refers to a GitHub Pull Request into the LC9
>REAL WORLD CASE
>Now, I'm always a little skeptical about using synthetic benchmarks for
>performance. However, both of the above are actually real-world
>examples. Furthermore, when running a rather large LCS project on an
>engine with PR6671, I got a 2x speed up - one particular input took
>3mins to process, rather than 6mins (one phase of processing actually
>saw a 5x speed up!).
So what I can't confirm is whether PR6671 has been implemented into a
current version of LC9, but what I will say is this, if it hasn't then
Malte can look forward to an eventual speed improvement in large Array
operations as Mark Wa has already identified this problem and is
working on a fix. If it has been implemented then Malte needs to take
a look at Mark Wa examples and see where he can use some of Mark Wa's
good code to replace his own poorly performing code.
How this thread diverged from a problem that was clearly resolved by
fixing poor code, to, what seems to me, 'our poor code should run just
as fast in LC9 as LC5', I don't know. Sorry.
More information about the use-livecode