Re: Weird performance issue

On Fri, Sep 23, 2022 at 4:44 PM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > Letting the engine do it for you is always faster. > Interestingly, *just* getting the names and ids for a 1500 card stack is only about 15 times faster using the functions rather than a loop

Re: Weird performance issue

Yep, I'm aware of cardnames. I don't have any memory of why I wrote it this way -- maybe I didn't trust the ordering of cardnames and cardids? Or maybe it made more sense to collect by hand than to stitch together the values? Or maybe I just sucked at that moment in time. gc On Fri, Sep 23, 2022

Re: Weird performance issue

Are you familiar with the cardnames function? Letting the engine do it for you is always faster. That doesn't answer your question though. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 23, 2022 5:46:24 PM Geoff Canyon via us

Re: Weird performance issue

On Fri, Sep 23, 2022 at 11:08 AM Mark Wieder via use-livecode < use-livecode@lists.runrev.com> wrote: > On 9/23/22 10:40, J. Landman Gay via use-livecode wrote: > > It may be related to the size of the stack. LC would have to load it all > > into memory before checking the cards. Also, do the resu

Re: Weird performance issue

My test stack had over a thousand cards in it, and was still fast checking the 1000th card. I've now added a field to each of a thousand cards and stuck text in it; the stack is over 12MB and still much faster than Navigator, which is under 1MB. Lock Messages does nothing as far as I can tell. t

Re: Weird performance issue

On 9/23/22 10:40, J. Landman Gay via use-livecode wrote: It may be related to the size of the stack. LC would have to load it all into memory before checking the cards. Also, do the results change if you lock messages? You also do a *lot* of work on both opening the stack and opening the card

Re: Weird performance issue

It may be related to the size of the stack. LC would have to load it all into memory before checking the cards. Also, do the results change if you lock messages? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 22, 2022 3:01:48

Re: Weird performance issue

Hmm, this is what "the stacks" returns for me: /Users/gcanyon/Desktop/nav tester 0.004608 /Applications/LiveCode 9.6.8.app/Contents/Tools/Toolset/palettes/script-editor/revscripteditor.rev 0.272558 /Applications/LiveCode 9.6.8.app/Contents/Tools/Toolset/palettes/tools-palette/revtools.livecodesc

Re: Weird performance issue

Something weird happened to my post. I modified your handler to access only those stacks that appear when calling the function “the stacks”. In all those cases, the return time was only a few tenths of a second. But “revNaviigator” does not appear on that list. So there must be a longer pathwa

Re: Weird performance issue

Geoff. I get over 5 seconds for the “revNavigatior” So I modified your handler just a bit, to only a But “revNaviigator” does not appear on that list. So there must be a longer pathway for LC to find a stack that certainly must be in memory, but that does not appear in the “stacks” list? Crai

Weird performance issue

I was testing something for Navigator and found the following: put the long seconds into T repeat 1 get there is a card 1 of stack "untitled 1" --get there is a card 1 of stack "revnavigator" end repeat put the long seconds - T into T put T -- puts 0.005 or so put the long seconds

Re: Livecode performance problem

Paul Dupuis wrote: > For strange legacy application reasons, when lines get added to the > set of fields (a frequency action by users - sometimes adding hundreds > of lines a day), the data has to be repackaged into this tab delimited > structure in a single variable to run some procedures on. >

Re: Livecode performance problem

he time (for my sample data, 24ms down to >>> 20ms.) >> >> Nice. >> Note, of course, that we're all going on the assumption that all four fields >> contain the same number of lines. >> >> > > Thank you all for the example of improving per

Re: Livecode performance problem

Short version: inserting between is a much slower process than after, as the entire field/string/whatever from the post of insertion has to be moved or otherwise handled. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this u

Re: Livecode performance problem

Thank you! The prior solutions have dramatically reduced the time - the WHOLE analytics process in its entirety because of the slowness of my old code was taking HOURS (like 6-10) - and is now down to 30-35 minutes with the prior solutions. I can't wait to tr the combine by columns method to s

Re: Livecode performance problem

I can't answer for anyone else, but for me - because I never thought about it :-) Combine by column - never used it before, so never thought of it. It's significantly faster, roughly 40% improvement over the previous best. Note, the spec requires that each line begins with the line number, so

Re: Livecode performance problem

I didn’t text the speed, but why not put fld A into x[1] put fld B into x[2] put fld C into x[3] put fld D into x[4] combine x by column return x > > I have a set of fields, call them A, B, C, and D. Each has the same > number of lines. Each field has different text (per line) > > I need to co

Re: Livecode performance problem

n the same number of lines. Thank you all for the example of improving performance over my clunky code. Yes, all the fields contain the same number of lines. For strange legacy application reasons, when lines get added to the set of fields (a frequency action by users - sometimes adding hundre

Re: Livecode performance problem

On 20/08/2022 00:03, Bob Sneidar via use-livecode wrote: It's probably a lot of text. The engine has to start from the beginning of every string then scan through for every cr or lf or cr/lf or whatever counts as a line break, until if finds the nth one. The more lines, the longer the scan t

Re: Livecode performance problem

On 8/19/22 16:03, Bob Sneidar via use-livecode wrote: It's probably a lot of text. The engine has to start from the beginning of every string then scan through for every cr or lf or cr/lf or whatever counts as a line break, until if finds the nth one. The more lines, the longer the scan takes

Re: Livecode performance problem

On 8/19/22 16:31, Alex Tweedly via use-livecode wrote: to trim about another 15% off the time (for my sample data, 24ms down to 20ms.) Nice. Note, of course, that we're all going on the assumption that all four fields contain the same number of lines. -- Mark Wieder ahsoftw...@gmail.com

Re: Livecode performance problem

On 19/08/2022 23:32, Mark Wieder via use-livecode wrote: It is indeed faster. Here's what I came up with. I'm not sure why 2000 lines of text in four fields should take that long, I came up with original code: 320 ms array version: 21 ms    put empty into vCombined    put fld "A" into v1   

Re: Livecode performance problem

It's probably a lot of text. The engine has to start from the beginning of every string then scan through for every cr or lf or cr/lf or whatever counts as a line break, until if finds the nth one. The more lines, the longer the scan takes each time, and the more text per line the exponentially

Re: Livecode performance problem

On 8/19/22 15:07, Bob Sneidar via use-livecode wrote: Off the top of my head: split v1 by tab split v2 by tab split v3 by tab split v4 by tab put the keys of v1 into tKeyList sort tKeyList ascending numeric repeat for each line tKey in tKeyList put tKey & tab & v1 [tKey] & tab & v2 [tKey]

Re: Livecode performance problem

Based on what Bob said, here is my version of that handler: on mouseUp local tA, tB, tC, tD, tAll, tStart, tEnd put fld "A" into tA put fld "B" into tB put fld "C" into tC put fld "D" into tD -- put the milliseconds into tStart split tA by cr split tB by cr split tC b

Re: Livecode performance problem

First optimization would be to put … & cr after vCombined and then delete the trailing from when done. Sent from my iPhone > On Aug 19, 2022, at 5:11 PM, Paul Dupuis via use-livecode > wrote: > > I have a set of fields, call them A, B, C, and D. Each has the same number > of lines. Each fie

Re: Livecode performance problem

Off the top of my head: split v1 by tab split v2 by tab split v3 by tab split v4 by tab put the keys of v1 into tKeyList sort tKeyList ascending numeric repeat for each line tKey in tKeyList put tKey & tab & v1 [tKey] & tab & v2 [tKey] & tab & v3 [tKey] & tab & v4 [tKey] & cr after tCombined

Livecode performance problem

I have a set of fields, call them A, B, C, and D. Each has the same number of lines. Each field has different text (per line) I need to combine the data - frequently - into a form that look like: C> For the number of lines in the set of fields. Currently I do this as follows: put empty int

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

THIS has to be one of the bugs we address ASAP. Thanks Curry for doing the leg work on this one. I hope the team is paying attention to this one. This is one of the things that a new user has no hope of being aware of. Thanks, Tom ___ use-livecode maili

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

I was having problems with SE on Windows randomly causing crashes just by clicking in the text are of SE. When I switched off all the bling, I never had another crash like that. I plan to slowly re-introduce the bling to see if I can identify which part causes the crashes. Regards, Bernard __

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Resurrecting this thread from September because ... now I've had a chance to go through my old bug reports, and found the one for this Script Editor slowdown! (It said "Pending Followup" so I just followed up on it.) For the people here that still see bad IDE/SE performance

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

able antivirus entirely; be safe! None of this is new; I listed 6 known factors and one more would be too much code; LC 7+ has performance issues that have been noted for years and are still being fixed. (I favor shorter code, and it has many perks. This is just one of them.) The IDE is not a hig

Re: AW: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Hi Lagi I just went back and repeated my steps from a couple of days ago. New start for IDE, new stack, pasted in the same 8,000 lines as a comment. And this time there was no slow down. So it does look like any such problems are less predictable than my initial test suggested. I toggled on then

Re: AW: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Hi Bernard, I didn't make myself clear - it can work for hours with no slowdown at 13,000 lines on an older computer there is just no pattern. Lagi On Wed, 8 Sept 2021 at 18:54, Bernard Devlin via use-livecode < use-livecode@lists.runrev.com> wrote: > I pasted 8000 lines of text into Script Ed

Re: AW: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

One thing to check is whether you are using a fixed width font, and if not whether you have the same performance issue with the SE when using one. On Wed, 8 Sep 2021, 18:52 Bernard Devlin via use-livecode, < use-livecode@lists.runrev.com> wrote: > I pasted 8000 lines of text into Scri

Re: AW: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

I pasted 8000 lines of text into Script Editor on Windows (just 1 large block comment). On typing chars take a couple of seconds to appear once there is that much text. Cut it down to 800 lines and it's fine. With 8000 lines switch off "live errors" and the slow typing issue is gone. I've asked

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

I also have seen the autocomplete stop and start working, and that on a Mac. It may have something to do with the length of the script. I have also seen the extreme slowdown issue on Windows script editor and also in the performance. Most of the performance hit is in the frequent saves I

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

> > some other Windows-specific speed issues did. > > Not "it". Instead a combination: > > 1. LC 7 Engine Performance issues. > 2. New Windows antivirus trends affecting disk access. > 3. Mediocre LC SE design with excessive disk access. > 4. Lack of LC Dev Team ade

Re: AW: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

dramatic difference in IDE speed, that would > help. (Unfortunately since the licensing changes, the available installers > for > these old versions require someone with a commercial license.) > > In relation to the second, by my count four people have now reported > harrowingly s

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Hi Ben, I did some testing using the CPU% in the task manager - i was trying to do some more before sending in my results. It looks like if it has been running for some time but the time is not "quantified" at the moment as I have not been working on my project much these last few months. When I

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

I don't use 6.7 anymore, but no, they do not. At least not to the degree they do now. Bob S > On Sep 8, 2021, at 05:13 , Ben Rubinstein via use-livecode > wrote: > > May I repeat my request that anyone experiencing these issues on Windows > (Andre, Lagi, Bob), could if possible confirm whe

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Ben: > It would be good to understand if this has always been an issue, > or whether it came in with the switch to LC7, as we know > some other Windows-specific speed issues did. Not "it". Instead a combination: 1. LC 7 Engine Performance issues. 2. New Windows antivir

Re: AW: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

y slow IDE performance on Windows. I think at least two have said it's fine for them. Could we get a catalogue of the setups which do and don't experience the issue? Ben On 08/09/2021 13:26, Tiemo via use-livecode wrote: The response of the IDE on Windows is harrowing slow. It's

AW: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

stein via use-livecode Gesendet: Mittwoch, 8. September 2021 14:14 An: Andre Garzia via use-livecode Cc: Ben Rubinstein Betreff: Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition) May I repeat my request that anyone experiencing these issues on Windows (Andre, Lagi, Bob), cou

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

May I repeat my request that anyone experiencing these issues on Windows (Andre, Lagi, Bob), could if possible confirm whether they find the same applies using LC 6.7? It would be good to understand if this has always been an issue, or whether it came in with the switch to LC7, as we know some

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

I mean the script editor mostly but also the rest of the ide has a bit of jank. Laying out interfaces on Windows has been worse than doing it on a Mac. The worse offender is the script editor though. > On 7 Sep 2021, at 23:28, Scott Morrow via use-livecode > wrote: > > Andre, when you say “so

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Andre, when you say “so bad” do you mean the script editor or… ? -- Scott Morrow > On Sep 7, 2021, at 12:57 PM, Andre Garzia via use-livecode > wrote: > > to be honest, the IDE on Windows has been so bad for me that it caused me to > switch back to a mac... __

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Welcome back, Andre! On Tue, Sep 7, 2021 at 12:56 Andre Garzia via use-livecode < use-livecode@lists.runrev.com> wrote: > to be honest, the IDE on Windows has been so bad for me that it caused me > to switch back to a mac... > > > On 7 Sep 2021, at 09:00, Ben Rubinstein via use-livecode < > use-l

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Yes, and this is really disconcerting. Not sure how many Mac vs. PC devs there are for LC, but I suspect it's weighed heavily towards Mac. I think in retrospect, it may have been better to retain UTF-8 as an option, that is be able to select unicode or not in an app. But I suspect that would be

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

to be honest, the IDE on Windows has been so bad for me that it caused me to switch back to a mac... > On 7 Sep 2021, at 09:00, Ben Rubinstein via use-livecode > wrote: > > I was wondering this too: when Lagi mentioned 'fix the IDE' I thought this > might be a reference to some of a number of

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

behalf of Bernard Devlin via use-livecode Sent: Tuesday, September 7, 2021 7:08:09 PM To: How to use LiveCode Cc: Bernard Devlin Subject: Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition) Without knowing anything other than "the IDE is like treacle" I loaded various

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

Without knowing anything other than "the IDE is like treacle" I loaded various stacks in Windows to see what the complaint could possibly be about. 8 seconds for IDE to start - no treacle on opening stacks 8 seconds to open Dictionary - no treacle on searching Dictionary (given it's loading 1000 p

Re: IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

It's worse than the unicode text issue. Saving stacks is from my setup 7 to 8 times slower in Windows than on a Mac, and I have tried numerous Windows configurations from bare metal to VMWare servers running on a robust host. In discussions in the past, it seems there isn't a lot Livecode can do

IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)

I was wondering this too: when Lagi mentioned 'fix the IDE' I thought this might be a reference to some of a number of usabiity snags - it didn't occur to me that it was just speed. I develop on a nine-year old MacBook and have never noticed a speed issue with the IDE. I wonder if it's possibl

Re: Slow performance on Big Sur

The screen is already locked on closeCard and unlocked on openCard. In between a bunch of stuff happens. Maybe that sequence of lock/unlock isn't working in Big Sur? On 12/16/20 3:46 AM, Pi Digital via use-livecode wrote: What about using ‘lock screen’? Then go card. For preopen it ‘shouldn’t’

Re: Slow performance on Big Sur

Hello all, We have tried to reproduce this issue on Big Sur, but with no success. We have filed a report for this issue - could you please attach a stack (and a recipe) that demonstrates the problem here: https://quality.livecode.com/show_bug.cgi?id=23037 If the stack is confidential, feel free

Re: Slow performance on Big Sur

What about using ‘lock screen’? Then go card. For preopen it ‘shouldn’t’ make a difference but I have found this to be a cause for stammering in the past. Don’t bother putting an ‘unlock screen’ at the end of the preopencard or opencard as it will unlock itself at the end of the open sequence a

Re: Slow performance on Big Sur

I had my client try it. Adding "wait 0 milliseconds" after a "go card" didn't make any difference really. The first four card changes were pretty fast, and after that it got slower and slower with each subsequent card change. I was watching her screen remotely but I couldn't see it due to how re

Re: Slow performance on Big Sur

gt; 49 inch curved screens!) running Big Sur and he sent a video showing slow > performance when populating a half dozen text fields from a custom property > - took about 3 seconds (in a standalone). > > > > Marty > > > >> On Dec 14, 2020, at 11:04 AM, J.

Re: Slow performance on Big Sur

customer with a brand new Mac Pro with tons of memory (and two 49 inch curved screens!) running Big Sur and he sent a video showing slow performance when populating a half dozen text fields from a custom property - took about 3 seconds (in a standalone). Marty On Dec 14, 2020, at 11:04 AM, J

Re: Slow performance on Big Sur

On 12/14/20 2:46 PM, Paul Dupuis via use-livecode wrote: On 12/14/2020 2:04 PM, J. Landman Gay via use-livecode wrote: My client is running Big Sur and says that changing cards in a stack causes a very slow, stuttering display. The background image appears in chunks and text in the fields comes

Re: Slow performance on Big Sur

On 12/14/2020 2:04 PM, J. Landman Gay via use-livecode wrote: My client is running Big Sur and says that changing cards in a stack causes a very slow, stuttering display. The background image appears in chunks and text in the fields comes in as sequential pieces. The order of the display varies

Re: Slow performance on Big Sur

I have a customer with a brand new Mac Pro with tons of memory (and two 49 inch curved screens!) running Big Sur and he sent a video showing slow performance when populating a half dozen text fields from a custom property - took about 3 seconds (in a standalone). Marty > On Dec 14, 2020,

Slow performance on Big Sur

My client is running Big Sur and says that changing cards in a stack causes a very slow, stuttering display. The background image appears in chunks and text in the fields comes in as sequential pieces. The order of the display varies, sometimes the text appears first, sometimes the background im

Re: AW: Re: I need some DataGrid performance help

ich 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 improve

AW: Re: I need some DataGrid performance help

Reduced to a consistent 1.5 to 2 minutes by revising the setting of datagrid column properties the columns themselves, widths, and alignments set all at one. Tooltips, sort type and sort direction set in a loop in revised code. I still do not understand why in the original code, when 1st set

Re: I need some DataGrid performance help

Mark Waddingham wrote: On 2020-05-06 17:36, Richard Gaskin via use-livecode wrote: A while back Mark Waddingham reviewed the situation and decided that getProp and setProp were indeed more rightly in the category of custom messages rather than system messages, and as such should ideally be immu

Re: I need some DataGrid performance help

On 5/6/2020 1:53 PM, Mark Waddingham via use-livecode wrote: In reality, 'lock messages' is a sledge-hammer and like a sledge-hammer it can cause fallout if not wielded carefully. Slightly off topic, but I have run into time where I wish I could lock a specific message or set of messages. So

Re: I need some DataGrid performance help

On 2020-05-06 17:36, Richard Gaskin via use-livecode wrote: A while back Mark Waddingham reviewed the situation and decided that getProp and setProp were indeed more rightly in the category of custom messages rather than system messages, and as such should ideally be immune to the effects of "loc

Re: I need some DataGrid performance help

On 5/6/20 5:35 AM, Paul Dupuis via use-livecode wrote: This code is called only when the data is changed such as columns added or removed or rows added or removed or both. What I do is set the data initially, then cache the existing setup in a local array. When something changes I can examine

Re: I need some DataGrid performance help

zryip theSlug wrote: > datagrids are using virtual properties, so you can't lock the > messages. Reminds me: we have a request to do away with that,since it complicates a lot of otherwise-powerful-and-simple things we can do with custom controls. A while back Mark Waddingham reviewed the sit

Re: I need some DataGrid performance help

Paul, datagrids are using virtual properties, so you can't lock the messages. tooltip, sorttype, and editability have only an effect if one interact with the datagrid. I do not think this is your issue. Plus, I ran in a similar problem when I updated DGH 2.5 with column color capabilities. One of

Re: I need some DataGrid performance help

On 5/6/2020 7:58 AM, zryip theSlug via use-livecode wrote: After each call to a column property such as dgColumnWidth, the datagrid is resized (header, column, rectangles, etc) This I did not know. Thank you. Instead of having them in the loop, prepare the column size, columns label, etc and

Re: I need some DataGrid performance help

On 5/6/2020 6:55 AM, Pi Digital via use-livecode wrote: What handler do you have this code? From what you are saying it seems it’s deploying this formatting script every time it redraws which itself is very inefficient and unnecessary. It should only have to deal with the data itself ideally.

Re: I need some DataGrid performance help

Paul, After each call to a column property such as dgColumnWidth, the datagrid is resized (header, column, rectangles, etc) Instead of having them in the loop, prepare the column size, columns label, etc and uses the table properties existing for setting all the values at once. In this case the r

Re: I need some DataGrid performance help

Hi Paul What handler do you have this code? From what you are saying it seems it’s deploying this formatting script every time it redraws which itself is very inefficient and unnecessary. It should only have to deal with the data itself ideally. Sean Cole Pi Digital Productions Ltd eMail Ts

Re: I need some DataGrid performance help

I’ve no idea if this could help or even if this may cause worse problems with a DG, so just a thought, but have you tested with Lock Screen, Lock Messages and/or Lock Updates while the repeat is processing? Failing that, I would try disabling each command in turn to find out if just one of them

I need some DataGrid performance help

I have a datagid operation that should be fast that is taking a long time and I don't understand why. I use a datagrid to display a table of data as part of an analysis. The columns are file names and the rows are selected phrases found in those files. The first column is the list of phrases (

RE: OMG text processing performance 6.7 - 9.5 - correction

Belay my claim about the offsets found from using an offset search on raw text and on the utf-8 version of that text giving exactly the same offset numbers for corresponding hits - they don’t of course. The offsets reported in the raw text are binary 8-bit character offsets, the offsets reported

RE: OMG text processing performance 6.7 - 9.5

One further comment … when talking about long text and not using lineOffset I really do mean long. Using source text the first 500 KB of Les Miserables, the times for simple Parse 1 offset search with skip for *both* raw text and utf-8 was 1 ms, and for lineOffset 10 ms and 14 ms respectively

RE: OMG text processing performance 6.7 - 9.5

Richard, here is a link to my test stack https://www.dropbox.com/sh/bbpe12p8bf56ofe/AADbhV2LavLP4Y3CZ8Ab8NGia?dl=0 The LesMiserables.txt file is included for convenience; it should be placed in your Documents directory.

Re: OMG text processing performance 6.7 - 9.5

Super thorough work there, Neville. Thanks. Could I trouble you to post code listings for the various algos? I'd like to try them on my MBOX archives, and they may also be useful for others looking for parsing routines in the archives. -- Richard Gaskin Fourth World Systems Neville wrote

Re: OMG text processing performance 6.7 - 9.5

On 2/4/20 6:43 PM, Colin Holgate via use-livecode wrote: Would have been neat if it took 24601 milliseconds. Chortle -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe

Re: OMG text processing performance 6.7 - 9.5

Would have been neat if it took 24601 milliseconds. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livec

RE: OMG text processing performance 6.7 - 9.5

Just for interest, and to see just how slow lineOffset is, I added a couple of more tests to the search for occurrences of “Valjean” in the Gutenberg English translation of Les Miserables. I also wanted find how filter performs. The searches were first applied to the raw binary text as read from

Re: OMG text processing performance 6.7 - 9.5

On 04/02/2020 22:12, Richard Gaskin via use-livecode wrote: The code I was using was similar to Alex' itemDel solution, but playing with all three together shows itemDel only slightly faster than delete, and both much faster than traversing in-place with "start at". You know I'm always hap

RE: OMG text processing performance 6.7 - 9.5

demonstrate the exponential decay in performance with long utf-8 text. For most searches I would think one could use the raw text as long as one was searching for an ascii string, false positives where the string of single bytes occurs inside multibyte characters would be extremely unlikely

Re: OMG text processing performance 6.7 - 9.5

Ralph DiMola wrote: > My initial timings was with an earlier v9 version. I will do some > timings on 9.5.1. In the meanwhile I wonder if doing a "delete char > 1 to n of myVar" is more expensive then "put char n to -1 of myVar > into myVar" as I do. I had thought the exercise was to obtain a list

RE: OMG text processing performance 6.7 - 9.5

mation Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Bob Sneidar via use-livecode Sent: Tuesday, February 04, 2020 2:45 PM To: How to use LiveCode Cc: Bob Sneidar Subject: Re: OMG text processing performance 6.7 - 9

Re: OMG text processing performance 6.7 - 9.5

Heresy! Burn the cretan!!! ;-) Bob S > On Feb 4, 2020, at 10:43 , Richard Gaskin via use-livecode > wrote: > > Hmmm It may be that Mark Waddingham was wrong in the guidance he gave > earlier about Unicode vs memcopy, but I wonder if there may be something else > here. ___

Re: OMG text processing performance 6.7 - 9.5

On 2/4/20 12:43 PM, Richard Gaskin via use-livecode wrote: J. Landman Gay wrote: On 2/3/20 2:19 PM, hh via use-livecode wrote: Parse1 is here always at least 30% faster than Parse2. I'm seeing the same thing, only more so. I searched for "the" in a 424K text file: parse1 = 11 ms parse2 = 11

Re: OMG text processing performance 6.7 - 9.5

J. Landman Gay wrote: On 2/3/20 2:19 PM, hh via use-livecode wrote: Parse1 is here always at least 30% faster than Parse2. I'm seeing the same thing, only more so. I searched for "the" in a 424K text file: parse1 = 11 ms parse2 = 111 ms Hmmm It may be that Mark Waddingham was wrong i

RE: OMG text processing performance 6.7 - 9.5

Of J. Landman Gay via use-livecode Sent: Monday, February 03, 2020 6:48 PM To: How to use LiveCode Cc: J. Landman Gay Subject: Re: OMG text processing performance 6.7 - 9.5 On 2/3/20 2:19 PM, hh via use-livecode wrote: Parse1 is here always at least 30% faster than Parse2. I'm seeing the

RE: OMG text processing performance 6.7 - 9.5

...@lists.runrev.com] On Behalf Of J. Landman Gay via use-livecode Sent: Monday, February 03, 2020 6:48 PM To: How to use LiveCode Cc: J. Landman Gay Subject: Re: OMG text processing performance 6.7 - 9.5 On 2/3/20 2:19 PM, hh via use-livecode wrote: > Parse1 is here always at least 30% faster t

Re: OMG text processing performance 6.7 - 9.5

On 2/3/20 2:19 PM, hh via use-livecode wrote: Parse1 is here always at least 30% faster than Parse2. I'm seeing the same thing, only more so. I searched for "the" in a 424K text file: parse1 = 11 ms parse2 = 111 ms The text was imported into a field using the property inspector, which I as

RE: OMG text processing performance 6.7 - 9.5

, February 03, 2020 3:19 PM To: use-livecode@lists.runrev.com Cc: hh Subject: Re: OMG text processing performance 6.7 - 9.5 Parse1 is here always at least 30% faster than Parse2. Yet another approach in LC 7/8/9 that I find to be very fast (especially for a lot of hits in large strings, e.g. when

Re: OMG text processing performance 6.7 - 9.5

Parse1 is here always at least 30% faster than Parse2. Yet another approach in LC 7/8/9 that I find to be very fast (especially for a lot of hits in large strings, e.g. when searching for "and" or "the"): -- Offset per ItemDelimiter -- Searches for pStr in pSrc using pCase function Parse0 pStr, p

Re: OMG text processing performance 6.7 - 9.5

Sannyasin Brahmanathaswami wrote: hhmm…. how do you "truncate the string and search from the beginning" ?? Can you give a code snippet example? BR I found this as well. Another thing, it's faster to truncate the string and search from the beginning than using a "start at" on the entire st

Re: OMG text processing performance 6.7 - 9.5

hhmm…. how do you "truncate the string and search from the beginning" ?? Can you give a code snippet example? BR I found this as well. Another thing, it's faster to truncate the string and search from the beginning than using a "start at" on the entire string when searching for all occurrenc

Re: OMG text processing performance 6.7 - 9.5

Ralph DiMola wrote: I found this as well. Another thing, it's faster to truncate the string and search from the beginning than using a "start at" on the entire string when searching for all occurrences of a string . This was counter intuitive to me until Mark explained that skipping chars require

  1   2   3   4   5   >