Re: Garbage collection (crashing on Windows)

2016-09-05 Thread Mark Waddingham
On 2016-08-22 14:47, Ben Rubinstein wrote: https://blogs.technet.microsoft.com/askperf/2007/03/23/memory-management-demystifying-3gb/ This looks like a great tip - before I go into the ring with the client's IT dept (always a tricky exercise) can I just check that LiveCode does have the

Re: Garbage collection (crashing on Windows)

2016-08-22 Thread Ben Rubinstein
Mark, Thanks so much for this detailed and very useful response. A few quick follow-up questions. 1) > https://blogs.technet.microsoft.com/askperf/2007/03/23/memory-management-demystifying-3gb/ This looks like a great tip - before I go into the ring with the client's IT dept (always a

Re: Garbage collection (crashing on Windows)

2016-08-20 Thread Monte Goulding
> On 21 Aug 2016, at 2:33 AM, Dr. Hawkins wrote: > > In that case, what are the several second pauses in the IDE, particularly > the editor (versions 5 & 7, maybe others) Do you happen to have bug report numbers for these pauses because they can probably be fixed? I’ve

Re: Garbage collection (crashing on Windows)

2016-08-20 Thread Mark Waddingham
Most likely the time it takes to layout the text for display - 'typesetting' (the process that converts a styled string into a list of glyphs and positions) is a very complicated and time consuming process. Mark. Sent from my iPhone > On 20 Aug 2016, at 17:33, Dr. Hawkins

Re: Garbage collection (crashing on Windows)

2016-08-20 Thread Dr. Hawkins
On Fri, Aug 19, 2016 at 10:42 AM, Mark Waddingham wrote: > LiveCode doesn't use what is generally referred to as 'garbage collection' > as it generally frees 'things' up as soon as they are no longer referenced. In that case, what are the several second pauses in the IDE,

Re: Garbage collection (crashing on Windows)

2016-08-20 Thread Dr. Hawkins
On Thu, Aug 18, 2016 at 11:09 AM, Jeanne A. E. DeVoto < revolut...@jaedworks.com> wrote: > I've had ugly crashes with large or complex arrays (that weren't anywhere > near the 4G limit). It's not just LiveCode where I trip over obscure bugs . . That's actually how I found met buy in Cray's

Re: Garbage collection (crashing on Windows)

2016-08-20 Thread Mark Talluto
Split would works for simple data sets. This made up example would support split just fine. > On Aug 19, 2016, at 8:29 PM, Monte Goulding wrote: > > Mark you could use the split command here if you don’t mind numerically > indexed arrays. > >> On 20 Aug 2016, at 9:07 AM,

Re: Garbage collection (crashing on Windows)

2016-08-20 Thread Mark Waddingham
Ah! Using repeat for each key is essentially using the keys of an array as a 'proper list' - it is probably the fastest way currently to iterate over a sequence of strings. In this case the value of each element in that array is immaterial - so the performance benefit comes iterating over the

Re: Garbage collection (crashing on Windows)

2016-08-19 Thread Monte Goulding
Mark you could use the split command here if you don’t mind numerically indexed arrays. > On 20 Aug 2016, at 9:07 AM, Mark Talluto wrote: > > command createArray > local tListOfRecordIDs, tTableID > > put fld "recordID data" into tListOfRecordIDs > put

Re: Garbage collection (crashing on Windows)

2016-08-19 Thread Mark Talluto
I do not remember how much of a performance boost we got from manipulating long lists this way, but if memory serves, it was quite beneficial. This code sample is just something I made up on the fly. Hopefully it demonstrates the value of this method. command createArray local

Re: Garbage collection (crashing on Windows)

2016-08-19 Thread mwieder
Ah, the wonders of paged memory. - -- Mark Wieder ahsoftw...@gmail.com -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Garbage-collection-crashing-on-Windows-tp4707560p4707624.html Sent from the Revolution - User mailing list archive at Nabble.com

Re: Garbage collection (crashing on Windows)

2016-08-19 Thread Mark Waddingham
With the current implementation of the engine, the only reason using empty is faster than using pValue is because the latter requires a variable lookup, the former is a constant. What are you using sValueCache for? Sent from my iPhone > On 19 Aug 2016, at 19:37, Mark Talluto

Re: Garbage collection (crashing on Windows)

2016-08-19 Thread Mark Talluto
> On Aug 19, 2016, at 10:42 AM, Mark Waddingham wrote: > > command shareAndStoreKey @xArray, pKey, pValue > set the caseSensitive to true -- this is assuming your values are > sensitive to case > if pValue is not among the keys of sValueCache then > put

Re: Garbage collection (crashing on Windows)

2016-08-19 Thread Mark Waddingham
Hi Ben, When I got to the end of this email I remembered something quite pertinent - you mentioned that the limit you were hitting was 2Gb... One thing to check is that the install of Windows you are running on cannot be poked to actually raise this limit to 3Gb:

Re: Garbage collection (crashing on Windows)

2016-08-18 Thread Ben Rubinstein
On 18/08/2016 19:09, Jeanne A. E. DeVoto wrote: At 3:28 PM +0100 8/18/2016, Ben Rubinstein wrote: The real problem is that the script was written originally 13 years ago, and the basic architecture was to load everything into large global arrays for cleanliness. I've had ugly crashes with

Re: Garbage collection (crashing on Windows)

2016-08-18 Thread Jeanne A. E. DeVoto
At 3:28 PM +0100 8/18/2016, Ben Rubinstein wrote: The real problem is that the script was written originally 13 years ago, and the basic architecture was to load everything into large global arrays for cleanliness. I've had ugly crashes with large or complex arrays (that weren't anywhere

Re: Garbage collection (crashing on Windows)

2016-08-18 Thread Richard Gaskin
Ben Rubinstein wrote: > The real problem is that the script was written originally 13 years > ago, and the basic architecture was to load everything into large > global arrays for cleanliness. Over that period, the size of the data > has multiplied over the years by 1-2 orders of magnitude

Re: Garbage collection (crashing on Windows)

2016-08-18 Thread Mike Bonner
Or you can probably delete the whole variable directly. On Thu, Aug 18, 2016 at 8:59 AM, Mike Bonner wrote: > If you switch to using an array key with your global variable, and then " > delete global gArray[yourkey]" it should release the memory. > > > On Thu, Aug 18, 2016

Re: Garbage collection (crashing on Windows)

2016-08-18 Thread Mike Bonner
If you switch to using an array key with your global variable, and then " delete global gArray[yourkey]" it should release the memory. On Thu, Aug 18, 2016 at 8:28 AM, Ben Rubinstein wrote: > Thanks Monte, Richard. > > As it happens this script isn't doing with properties,

Re: Garbage collection (crashing on Windows)

2016-08-18 Thread Ben Rubinstein
Thanks Monte, Richard. As it happens this script isn't doing with properties, which is good (or bad since that potentially easy fix isn't available to me!) but that's a useful tip to remember. I've already moved some very large functions to passing by reference. The real problem is that the

Re: Garbage collection (crashing on Windows)

2016-08-18 Thread Richard Gaskin
Ben Rubinstein wrote: Please refresh my memory: is there any way to cause/allow garbage to be collected without ending all script running? I have an app which process large amounts of data. It runs fine on Mac, but on Windows intermittently (but not frequently as the application data source,

Re: Garbage collection (crashing on Windows)

2016-08-17 Thread Monte Goulding
There are certainly a number of tricks you can use to reduce the memory usage of your app. One interesting one I learnt recently after an internal discussion was because LiveCode copies values that have multiple reference when they are mutated and custom properties are arrays linked to the

Garbage collection (crashing on Windows)

2016-08-17 Thread Ben Rubinstein
Please refresh my memory: is there any way to cause/allow garbage to be collected without ending all script running? I have an app which process large amounts of data. It runs fine on Mac, but on Windows intermittently (but not frequently as the application data source, which fluctuates, is