AW: Re: I need some DataGrid performance help
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
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
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!)
Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
More information about the use-livecode