Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin]

Curry Kenworthy wrote:

 > http://curryk.com/NeverGonna.mp4

Thank you for the link to test results relating to specific issues.

What bug reports can I find those test stacks attached to?

I'd like to follow their progress, and perhaps re-run them to see where 
there may have been changes after the seven builds delivered since v9.0 
was released. Happy to help steward issues along as best I can; 
supporting the QA process benefits my work as well.


 > Oh boy - I was ALWAYS gullible enough to fall for the "concrete
 > concerns" type of line every single time, and rush off to make a newer
 > list..

Not really needed.  When you use the RQCC you'll see that searches are 
expressed in the URL, so when communicating about several issues at once 
you needn't really need to spend any time writing each of them down, you 
can copy the search URL you've already bookmarked to monitor issues 
you're following.


 > And testing indicated that it's almost certainly NOT just a Unicode
 > thing.

Kudos.  I've have neither the time nor the C++ experience to examine the 
code well enough to rule out all possible impact from type coercions 
which may involve encoding operations.

What I have seen in many RQCC discussions is that fixing legacy bugs 
sometimes adds additional overhead.

Admittedly going out on a limb here, but I'm reasonably confident the 
team is neither willfully introducing new code to slow things down for 
no reason, or doing slopping haphazard work with no regard for quality.

With that assumption, when I see performance degradation I'm inclined to 
recognize that what I have is not a lengthy declaration opining about 
what constitutes professional code, or any declaration at all.  What I 
have is inherently a question: Why is this specific operation slower?

When I pose questions as questions I usually get answers in reply, and 
often quite helpful ones, e.g.:

 > Mark Waddingham:
 >
 >  > It hasn't as yet - that PR
 >  > (https://github.com/livecode/livecode/pull/6671) has actually
 >  > turned into a mini-grab bag of things [...]
 >
 >  > - reduction of memory usage of the 'handle' structures used to
 >  > hold values (particularly on 64-bit)
 >  > - faster processing of integer index access in arrays
 >  > - faster short-path array access (both storing and fetching) [...]
 >
 > Yes!!! Just what I was hoping to hear, that this is still in the
 > works. Thank you, sir. It should help a great deal.


My interest is in getting results. I wish I had time for anything as 
colorful as "circling wagons", but alas like most people here I simply 
have software to deliver and need to stay focused where I can on 
specific actionable outcomes.

To that end, my method here is as straightforward as with anyone I work 
with:

1. Learn from the people doing the work I'm relying on
    how best to support their efforts.

2. Then I do that.

FWIW, using this method I see a lot of issues I report get resolved. 
Some very quickly.  And the ones not yet resolved are usually 
accompanied by an explanation of what's involved so I can understand the 
priorities at play.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com