Performance issues LC8 versus earlier versions.

[Monte Goulding]

> On 24 Aug 2016, at 9:50 AM, Monte Goulding <monte at appisle.net> wrote:
> 
> 
>> On 24 Aug 2016, at 9:06 AM, Monte Goulding <monte at appisle.net <mailto:monte at appisle.net>> wrote:
>> 
>> After reviewing the code path I see that there is an attempt made to parse the binary value into a number to try and compare numerically before doing the binary comparison. It may be we can change the order here and if both left and right are binary just compare the memory first.
> 
> I’ve made this patch https://github.com/livecode/livecode/pull/4409 <https://github.com/livecode/livecode/pull/4409> to get the ball rolling on improving the performance here. However, it will currently break any number comparisons where the strings are different but the numbers are the same such as octal to decimal. It only breaks them if they are both currently in binary strings. It is possible I think to work out if both sides are binary and of a size that they are clearly not numbers (or at least LC can’t represent them as numbers) then do a binary comparison there. Then try and covert to numbers and then check again if they are binary. Of course I may be worried over nothing because people should be decoding binary strings before they try and use them as numbers anyway...
> 
> Just moving the code as I did above brought my test of your code on an 8.5 MB file down from 60ms to 5ms.

Hi Alex

To avoid breaking the behavior of octal to decimal number comparison if they both happen to be in a binary string at the time of comparison I didn’t think it was a good plan to leave that binary comparison check above the number check… however, I think I’ve come up with a better solution anyway. When converting binary strings to numbers the engine first encodes it as native encoded string then parses the bytes to work out if they are a valid number. What I’ve done is first check if the binary data is longer than can be converted to a number and then stop trying to convert it to a number there. It is about 10 times faster for your use case as far as I can tell. Unfortunately it won’t make 8.1.0.

Cheers

Monte