AW: Re: I need some DataGrid performance help

Curry Kenworthy curry at pair.com
Thu May 7 23:31:01 EDT 2020


(I know that Paul understands tradeoffs very well, so he already knows 
this, but for the benefit of others....)

Maybe some concepts are so simple, people never take them seriously:

- You reap what you sow. You get the cake you bake.

- Comparisons: 1 < 2

- Complexity often reduces efficiency.

- Traveling farther at the same speed takes longer.

- Habits guide behavior and affect outcomes.



Like it or not, these are (in general) true. Coding without such 
principles is a handicap.

So looking at Field versus DataGrid (a collection of fields and more):

- Which is simpler?

- Which would you expect to deliver faster performance in most cases?

- Do you understand the tradeoffs?

- Do you understand your own goals?



Unfortunately the DataGrid is not as well-coded as it could be. 2 
minutes, let alone 30, is ridiculous. That's one thing. Hopefully it 
will be improved.

But imagine if it WERE coded incredibly well, and optimized to the max 
already today. Do you still understand the tradeoffs versus your own goals?

Is 10 < 1, or is 10 > 1?

(In reality the comparison might be 100 to 1 or even 1,000 to 1. But the 
overall answer is still the same.)

Do you expect (in all probability, with reasonable assumptions and 
maintenance versus weeds) to gather the type of crop you've planted at 
the harvest, or do you expect something else - something unrelated - to 
magically grow in its place?

(Some people hate general principles, but they can be applied 
efficiently to a large number of specific cases. I like efficiency and 
good outcomes.)



That's the DataGrid itself, and the logic of choosing to use it. Now 
let's look at the USER code.

I couldn't help but notice these lines:

 > repeat with i=2 to the number of lines in tColumnNames
 > put line i of tColumnNames into tColumnName

That won't have a negative impact in this specific case, but why do it?

It's a bad coding habit that slows down a lot of code. In fact it's the 
stereotypical LC code speed bump syntax. Seeing this in a post about 
performance is counterintuitive, because it's not in the performance 
mindset.

Maybe it's valid to have a love for this particular syntax and use it 
wherever it doesn't cause harm, but it's a dangerous habit because 
habits guide individual actions. Easy to forget, likely to cause harm 
elsewhere. Plus it spreads to other coders. A bad meme! That's why I 
like to make optimized syntax my habit and my default. It pays.

 > Therefore, I have to use a loop anyway

True, but loops are generally bad (performance-wise) and the more you do 
inside them, the worse it gets. So if you have a chance to put anything 
OUTSIDE the loop, why shouldn't that be the FIRST instinct? Again, 
habits and outcomes.

 > I still do not understand why in the original code, when 1st set in
 > a session it took 3 min and on subsequent updates in the same session,
 > it took 30 minutes. The datagrid must be slow erasing certain
 > properties for updating.

I agree - either that or the content. Maybe file this as an LC bug!

But the nature of DataGrid (a collection of many fields, and much more!) 
is inherently complex, so there will always be relative limits on 
performance. More so the way it currently works. That's why I've never 
been a huge fan. How often should we use it? When we do, just remember: 
we get the cake we bake. Pros and cons included.

Therefore (considering you're still at 2 minutes) if at all possible, 
don't set these DG properties by code at runtime. Get the DG set up the 
way you want it, save it that way, fill the data at runtime. I know 
you'll get it working well as you always do!



Did someone suggest using a field? No, I didn't say that. Not in so many 
words. :) Take care!

(And BTW, a big thank-you to my late father Bill Kenworthy, who worked 
on military aircraft and high voltage electricity, and who taught me the 
principle of using simplicity for increased efficiency and performance 
at around the age of 7. I started coding at age 8. Still the most 
important professional lesson I've ever learned in a lifetime. I 
remember we were in the backyard when he explained it. Can't remember 
exactly what we were working on, but what a lesson. Thanks Dad!)

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/




More information about the use-livecode mailing list