The end of XTalk / LiveCode for me

[stam]

I personally use XOJO (neé RealBasic) for web apps. Mainly because apart from the much faster performance and loading of websites, the IDE is drag & drop GUI IDE that is well suited for rapid visual development. Not sure how that compares with the other basic variants - however it is easier better than B4X where a visual layout designer is separated from any coding - XOJO is more like LiveCode in that respect.

[stam]

Running it on my 2016 MBP will be a true test as I've used OpenCore Patcher to install MacOS Sequoia 15.5 on it, even though the last officially supported OS for this is MacOS Sierra - so there will be extra overhead for the unsupported, near-current OS as well (the current 15.6 is not yet fully supported in OpenCore Patcher).

No one probably cares about this, but just as a follow up to my previous post:

Background
I ran a speed test on an old MacBook Pro (2016 Touchbar 15" MacBook Pro: 2.7 GHz Quad-Core Intel Core I7 with 16 Gb RAM). This machine's officially latest permitted OS is macOS Sierra which is pretty much useless (Safari on Sierra can't even display half the websites I use!) and since the touchbar MBP is pretty much impossible to run Linux on (I've tried about 8 distros - drivers are the problem with all, most fail to even detect keyboard/trackpad, all fail to detect sound/wifi), I decided to bypass MacOS' restrictions for this legacy/unsupported laptop, and installed MacOS Sequoia 15.5 on this using OpenCore Legacy Patcher. While this works, it is clearly a much more taxing OS for this machine and will likely negatively impact test results.

The machine I tested this on originally is a 2023 16" M2 Pro MacBook Pro with 16 Mb RAM, running MacOS Sequoia 15.6.
The test was to load 10,000 rows of 12 columns of random numbers into a data grid. I repeated the test for a polygrid - on both macines I am using LiveCode Create DP8 in 'Classic mode' -- equivalent to LiveCode 10.

Previous testing
On the 2023 machine, it takes on average 100 ms to load the dataset into a DG and about 6 ms to load into a polygrid widget. Scrolling was completely fluid with no perceptible delay/lag scrolling back and forth the 10,000 records.

Repeat testing on older machine
On the 2016 MBP this took on average 550 ms to load the datagrid and while there was no visible stuttering there was slightly lower frame rate when scrolling, with the net result of this not feeling completely fluid, but there was no actual stuttering.
Loading the polygrid widget with the same data was much quicker: 6 ms. However on scrolling there was more of a lag (when moving the scrollbar there was maybe 0.5 sec delay until the scrolling caught up). Datagrid was much more fluid.

Findings
So while, as expected performance is worse on a nearly 10 year old laptop running a heavy, unsupported MacOS, performance was OK-ish in my opinion. Loading times as expected were much faster for the polygrid widget at 6 ms and palpably slower with DG (about 0.5 seconds so just long enough to notice - but for 10,000 records that did not see unreasonable).

I did not expect the data grid to scroll much smoother than the polygrid - so this was a surprise. Scrolling the widget was slower in the sense that moving the scrollbar led to about 1 sec delay for the scroll to catch up whereas this was much quicker with data grid - so score +1 for the venerable DG!

In order to attempt replicating the OP's woes, I limited the number of rows to 200 - as expected performance for both DG and PG were much improved with much less perceptible delay on the 2016 machine.

Web
The worse performance is not limited to LiveCode - I ran the HTML speed the HTML speed test in my previous post.
New machine: 1 ms virtualised render, 1400 ms full render
Old machine: 10 ms virtualised render, 2800 ms full render
On the old machine, scrolling was fluid when using trackpad (more fluid that LC), but when scrolling the scrollbar there was about 0.5-1 second lag for the data to update in the HTML table.

I have no experience using LC to generate web apps: I just ticked the 'web' option in the standalone application settings and ran these again - this was truly a miserable/extremely poor performance, much more on par with what the OP describes, but I don't know how much of that is my ignorance as opposed LC limitations.


Conclusions
My conclusions is that overall, desktop apps perform adequately on an old machine. On newer M-series processors this runs entirely fluidly.
I was surprised to see that with large datasets, scrolling the data grid on the old machine performed visibly better than PolyGrid widget.

It may well be we have been arguing apples and oranges with the OP referring exclusively to web apps and me referring to desktop apps - and the two are really not equivalent. The web apps I was able to produce performed as badly as described by the OP, but of course most here think of LC as a desktop app where performance there is vastly superior to what is described.

Based on this limited testing as a web app, I would probably side with with the OP in not recommending LC for web apps - even in LC Create performance seems poorer (although I was unable to successfully export a web app from LCC - the html page produced just shows an endless spinner...). I personally will not be switching to LC for web apps for the time being either and will stick with XOJO...

Again, no one probably cares, but just setting the record straight on this...

[MichaelBluejay]

It may well be we have been arguing apples and oranges with the OP referring exclusively to web apps and me referring to desktop apps - and the two are really not equivalent

No. I have never made a web app with LiveCode, all my LiveCode apps are desktop. My Data Grid in my desktop app scrolls glacially, painfully slowly (and is the only thing on my old Mac that scrolls painfully, glacially slowly).

[stam]

No. I have never made a web app with LiveCode, all my LiveCode apps are desktop. My Data Grid in my desktop app scrolls glacially, painfully slowly (and is the only thing on my old Mac that scrolls painfully, glacially slowly).

I remain unable to replicate your experience.

As an additional test i ran the same on an even older Mac which is purely running Linux: Mid-2012 retina MBP with 16 Gb RAM running Linux Mint 22.1 (XFCE - changed to Plasma 5.27). Since i can't run LC Create on this, i installed community 9.6.3 and ran the same test.

This actually performed significantly faster than the 2016 Machine running Sequoia (probably indicating the relative impact of each OS - the more modern MacOS is much more taxing than Linux Mint XFCE (it's a real pity i cannot get any flavour of Linux to run on my touchbar MBP). The average time to load all the data is 400 ms; it scrolls completely fluidly all 10,000 records back and forth.

Your complaint of a 'glacially slow datagrid' is not a common one and one i have not been able to replicate on any of my hardware.
What is your setup? (hardware/RAM/MacOS/LC version?)

[dunbarx]

Michael. Stam.

Please keep on this. For your sake in particular, Michael, but it may throw light on an issue we have not yet seen.

Craig

[MichaelBluejay]

Craig,

I always just thought that the nature of Data Grid was that it scrolled super slowly, from the first time I used it in 2010. I was surprised to hear that others can scroll faster even on older equipment. If there are any kind of tests you'd like me to perform to report the results I'm happy to do so. My old Mac is iMac 27" 2014 (i7-4GHz, 32GB RAM), MacOS 11.7.10, running LC 9.6.3. I can't check on my 2022 Mac Studio M1, because as I mentioned, both 9.6.3 and the OpenXTalk fork won't launch on that computer.

[dunbarx]

I run a couple of iMac 27's as controllers for production machines. I will try to scroll a large DG and see how it goes.

Craig

[richmond62]

Can anyone point me to:

The last LC version with DG version 1,

and

The first LC version with DG version 2?

[stam]

Craig,

I always just thought that the nature of Data Grid was that it scrolled super slowly, from the first time I used it in 2010. I was surprised to hear that others can scroll faster even on older equipment. If there are any kind of tests you'd like me to perform to report the results I'm happy to do so. My old Mac is iMac 27" 2014 (i7-4GHz, 32GB RAM), MacOS 11.7.10, running LC 9.6.3. I can't check on my 2022 Mac Studio M1, because as I mentioned, both 9.6.3 and the OpenXTalk fork won't launch on that computer.

Have you considered creating a new user account (to ensure there is no interference from other software etc) and testing it on your older iMac? Just to rule out other confounders...

I can resurrect a old Mac mini from around 2010-2012 to test again on a 'desktop' type environment (I've been meaning to install Linux on it anyway, probably Elementary OS if I can get the wifi working).


PS: If you're not specifically using your iMac for Mac-only software you I can heartily recommend Linux as an alternative OS, as your machine is now obsolete and is not receiving security updates. You can 'live-test' it by downloading an .iso disk image from the site and using Balena Etcher to 'burn' this to a USB stick (32 Gb recommended). You can then boot from the USB and test prior to installing.
Linux Mint is probably your best bet for compatibility with drivers etc, and easy to install and use; Elementary OS is a very Mac-like distro. I'm running Linux Mint XFCE edition (less resource intensive) on my 2012 MBP and I've changed its desktop to KDE Plasma 5 which is more configurable and there are global themes that make it convincingly (at least at first glance) look and behave like MacOS.

[MichaelBluejay]

I just did some more testing. Again:

iMac 27" (2014, i7-4GHz, 32GB, Mac OS 11.7.10)

I tested 3 Data Grids, each about 1200 pixels high with about 200 rows, and either 6 columns of data or only six columns visible, with each cell having 4-40 chars depending on the cell (usually ≤12) on my regular Mac user account, and on a brand-new Mac user account, after a restart with no other apps running. Performance was similar in all 3 stacks.

Stack 1: My homegrown accounting software (never ready for a public release).
Stack 2: A brand-new stack I just created, with random data.
Stack 3: The test stack that stam created, after reducing the data to 200 rows and resizing the grid to 6 columns wide and 1200 pixels wide.

(A) Grabbing the thumb and dragging to the extreme top or bottom: ≤1 second. Good.

(B) Scrolling from the extreme top to bottom (or vice versa), by swiping my Magic Mouse: 3 seconds. Almost acceptable. Presumably it would be about 1.5s on a modern Mac, definitely acceptable. On the other hand, even on my old Mac, Safari 16.6.1 can scroll a page twice as long as my LiveCode tests in <1s. So Data Grid seems pretty sluggish by comparison.

(C) Starting a scroll operation: up to 2 seconds. Sometimes when I swiped the mouse, nothing hapenned for about 3s until it deigned to start scrolling. Weird.

(D) Reversing the scroll direction: up to several seconds. This one is horrible. As I'm scrolling up or down and then try to start scrolling the other way, LC never immediately reverses the scroll direction like Safari. It's like it buffered lots of the scroll down action, and was trying to catch up to that action before reversing. Using stam's test stack with the 10k rows and filling the scroll buffer, it took *12 seconds* to start reversing.

[stam]

A modern Mac with Apple silicon (M-series processors) will be much more than twice as fast in my experience.

However I still don’t experience what you do, even on old machines. And I’m pretty sure if everyone experienced such unusable performance there would be a storm of posts about this from many others, as it is a key interface element.

Did you create a new account to test? Also may be worth booting temporarily in safe mode and testing, just to rule out other confounders, as there may be something else interfering (it would be useful for all to know if that’s the case).

[jacque]

It's like it buffered lots of the scroll down action, and was trying to catch up to that action before reversing. Using stam's test stack with the 10k rows and filling the scroll buffer, it took *12 seconds* to start reversing.

I don't have an answer but I can confirm that the preloading of subsequent rows does happen.

[MichaelBluejay]

A modern Mac with Apple silicon (M-series processors) will be much more than twice as fast in my experience.

The published CPU benchmark for my Studio M1 is 2x of my iMac 27" 2014 for single-core. Maybe LC's Data Grid uses multicore for scrolling, but I doubt it.

Did you create a new account to test?

Yes, as I said.

Also may be worth booting temporarily in safe mode and testing...

I couldn't get my iMac to boot in safe mode. I then tried resetting the NVRAM via the keyboard but that wouldn't work either. I unplugged everything and took the batteries out of my Bluetooth keyboard, plugged in an Apple USB keyboard, but still no dice. I reset NVRAM via Terminal but still couldn't reset it from the keyboard or start in safe mode with the shift key. I followed the instructions for resetting the SMC, no change.

So, maybe my Mac has some problem, but it's a curious problem that affects only the Data Grid in LiveCode. Everything else works fine.