OMG text processing performance 6.7 - 9.5

matthias_livecode_150811 at m-r-d.de matthias_livecode_150811 at m-r-d.de
Thu Jan 30 10:55:44 EST 2020


Ben,

what DB are you connecting to?

We are running here a VM with Windows 2019 and MS SQL 2017. On a Windows 10 64bit VM we are using the 32 bit Microsoft ODBC Driver 11 for SQL Server to connect from our  32bit LC standalone to the MSSQL server, although 64bit ODBC Driver 11 is installed. But i cannot remember, if the 32bit driver was installed separately or was automatically installed when the 64bit ODBC Driver11 was installed.

-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 30.01.2020 um 14:20 schrieb Ben Rubinstein via use-livecode <use-livecode at lists.runrev.com>:
> 
> I'm looking for a hints about where the speed has gone in the current (Unicode era) LiveCode text processing. I've been vaguely aware that text processing performance suffered in the transition, but haven't needed to focus on it before.
> 
> The context is that I'm finally forced to replace an app that's been processing data for a client for well over a decade. To date the standalone has been built on LC 6.7.11; but now we need to put it on a new platform with 64-bit database drivers. The performance has gone through the floor, through the floors below, through the foundations, and is on its way to the centre of the earth.
> 
> The first stage of the app - which retrieves a load of data from various databases and online sources, does minimal processing on it, and dumps it to cache files - is approx 2x slower. The main core of the app, which loads this data in and does a vast amount of processing on it to generate various output data and reports, has gone from 12 minutes to over *six hours*.
> 
> (The server itself is different, and running Windows Server 2016 rather than Windows Server 2008, rather than but they're both VMs, quite likely on the same underlying hardware, and if anything I'd expect the new server to be more performant. Of course I assume that a new version of the OS will always be slower.... )
> 
> The coding is gnarly - the oldest parts are probably at least 15 years old - and I've no doubt it could be made more efficient; but we don't have time or budget to rewrite it all. So, are there known gotchas, functions which have taken a much greater hit than others, that I could concentrate on to get the most ROI in speeding this up?
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



-
Matthias Rebbe
Life Is Too Short For Boring Code





More information about the use-livecode mailing list