Re: Performance issues LC8 versus earlier versions.

> On 25 Aug 2016, at 5:49 PM, Alex Tweedly wrote: > > That is wonderful - thanks Monte. > btw - I opened a bug report to keep track of it, and so you'd have somewhere > to hang the change on to - 18254 FYI I have also added the length check to non-binary strings to speed up comparisons of tho

Re: Performance issues LC8 versus earlier versions.

On 25/08/2016 04:23, Monte Goulding wrote: 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… howeve

Re: Performance issues LC8 versus earlier versions.

> On 24 Aug 2016, at 9:50 AM, Monte Goulding wrote: > > >> On 24 Aug 2016, at 9:06 AM, Monte Goulding > > 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 d

Re: Performance issues LC8 versus earlier versions.

> On 24 Aug 2016, at 9:06 AM, Monte Goulding 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 an

Re: Performance issues LC8 versus earlier versions.

> On 24 Aug 2016, at 8:23 AM, Alex Tweedly wrote: > > On 22/08/2016 15:47, Richard Gaskin wrote: >> Alex Tweedly wrote: >> >> > Would caseSensitive make it faster ? >> >> In theory yes, since it avoids having to run the internal equivalent of >> toLower on each thing being compared. >> > But

Re: Performance issues LC8 versus earlier versions.

On 22/08/2016 15:47, Richard Gaskin wrote: Alex Tweedly wrote: > Would caseSensitive make it faster ? In theory yes, since it avoids having to run the internal equivalent of toLower on each thing being compared. But since these are bytes, not chars, that doesn't apply. However in some re

Re: Performance issues LC8 versus earlier versions.

On 22/08/2016 22:40, Ali Lloyd wrote: Is the speed difference still there without the `add 1 to temp` line? Yes. btw - 7.0.5 gives identical timings to 8.1 (probably what you'd expect, but thought I'd throw it in as useful info). -- Alex. ___ use

Re: Performance issues LC8 versus earlier versions.

> I would not have thought that caseSensitive should matter, since these > are bytes not characters - or is that being naive of me ? This is correct. > Would caseSensitive make it faster ? No, provided the internal representation remains binary, which will be true provided you are using binfile,

Re: Performance issues LC8 versus earlier versions.

Alex Tweedly wrote: > Would caseSensitive make it faster ? In theory yes, since it avoids having to run the internal equivalent of toLower on each thing being compared. However in some recent experiments involving pattern matching on text I was unable to measure a difference. That shouldn't

Re: Performance issues LC8 versus earlier versions.

Hi Monte, here's the script - the actual file could be any 20Mb or so jpg. on mouseUp put URL ("binfile:/Users/alextweedly/Dropbox (Personal)/Pictures/2016/101_0818/IMGP0021.JPG") into tData1 put URL ("binfile:/Users/alextweedly/Dropbox (Personal)/Pictures/2016/101_0818/IMGP0021.JPG") in

Re: Performance issues LC8 versus earlier versions.

Hi Alex It is always good to have them in the bug db so when know what people are running into. I know there was a big push during the LC 8 DP phase to try and get performance closer to LC 6. Actually after looking into this I wouldn't mind seeing your benchmark script as I can’t really see ho

Performance issues LC8 versus earlier versions.

I just discovered that part of my simple benchmark code I was doing for my photo apps was incorrect. I was being caught out (I think) by the implementation of 'copy-on-write' in LC8. My simple benchmark did (in essence) put URL("binfile:/path/to/verylargefile.jpg") into tData1 put tData1